For the new Firefox theme/UI we would like to introduce a "Home Tab"; moving the functionality of the home button to a persistent tab attached to the far left of the Tab Bar. Visually this tab looks like a mini-tab containing only the Home glyph. This tab initially will just take you to your home page. Any links clicked on this page would spawn a new tab. This would serve as a good introduction to tabs for users not accustomed to them. This will be the introduction of the Home Tab. In the future enhancements will include making a locally hosted page with access to history, add-ons, bookmarks, etc. Opening up possibilities for creating a user centric home page. See attachment for mockup.

Will there be a bug filed for the creation of App Tabs? https://wiki.mozilla.org/Firefox/Projects/3.7_and_4.0_Theme_and_UI_Revamp/Direction_and_Feedback#Introduction_of_App_Tabs_.28or_Persistent_Tabs.29

(In reply to comment #1) > Will there be a bug filed for the creation of App Tabs? > > https://wiki.mozilla.org/Firefox/Projects/3.7_and_4.0_Theme_and_UI_Revamp/Direction_and_Feedback#Introduction_of_App_Tabs_.28or_Persistent_Tabs.29 Yes. I will be filing some additional bugs this week.

Is the home tab still being rolled out or has it gone the way of the App Tabs? I ask because with the new customisable tab bar, you may feel it's easier just to let people put the home button on the tab bar? Though I hope not.

(In reply to comment #3) > Is the home tab still being rolled out or has it gone the way of the App Tabs? > I ask because with the new customisable tab bar, you may feel it's easier just > to let people put the home button on the tab bar? Though I hope not. Are you saying App Tabs has been scrapped?

(In reply to comment #4) > (In reply to comment #3) > > Is the home tab still being rolled out or has it gone the way of the App Tabs? > > I ask because with the new customisable tab bar, you may feel it's easier just > > to let people put the home button on the tab bar? Though I hope not. > > Are you saying App Tabs has been scrapped? Though I can't remember which bug, I recall reading that they wouldn't make it into 4.0. Hopefully someone will correct me if I'm wrong.

Home tabs and app tabs are still targeted for 4.0

Since the home tab is such a major part of the browser, I think it should carry more weight. Maybe including the word "home" to the button will make it horizontally bigger and more significant.

(In reply to comment #8) > Since the home tab is such a major part of the browser, I think it should carry > more weight. Maybe including the word "home" to the button will make it > horizontally bigger and more significant. I think this should only be so if the user has toolbar buttons to show icons and text, otherwise we'll annoy the user.

(In reply to comment #9) > I think this should only be so if the user has toolbar buttons to show icons > and text, otherwise we'll annoy the user. Since most browsers today do not have the text, I think you should just be defaulted to what it is today. I just love Internet Explorer 6's toolbar where the text is on the right side of the icon. Unfortunately, Firefox only allows you to show icons and text where the text is underneath the icon which looks a lot like Netscape. Also, I just want the text on some particular buttons that I use often. I hope the next Firefox version has this feature as an option in the preferences. It doesn't have to be the default option.

So instead of making UI thin, simple, effective and elegant, you want it rather filled with big tabs, unnecessary texts and other garbage? Great thinking.

If you take a look at recent versions of Microsoft Word, you see that the most used functions have text and are much bigger than the less frequently used functions. In addition there is description under the group of icons describing the category. Some might say that this is unnecessary and is a waste of space but I find it quite useful sometimes.

True, but Office 2007+ has Ribbon. It's designed to have big icons and texts. You can't compare Ribbon's strufcture and philosophy with Firefox's UI.

How will the home tab handle multiple home pages? I have an idea about it, and I will upload (right away) a mockup that should explain it fairly simply. Still, absolutely no idea who I should talk to about my concept for the in-content preferences panel. -mockup coming up!-

Since when is Firefox capable of handling multiple homepages?

This is the mockup I promised in my comment above.

(In reply to comment #15) > Since when is Firefox capable of handling multiple homepages? Since 1.5, I believe. You just separate them with a | , or you can click "Use current pages" if you have multiple tabs open in the current window.

>Still, absolutely no idea who I should talk to about my concept for the >in-content preferences panel. Best person to talk to is Limi. Something we've been thinking about is slightly altering the concept of Home in Firefox 4. If the user has a home page (or pages) that are not the default Firefox Start page, we were thinking about exposing these as app tabs (although with full chrome). So this way the previous concept of "home page" really means what app tab gets shown on launch. These app tabs will have the favicons for the sites. The user can still remove the Firefox Home tab, but we don't want the home tab to be too easy to override. This is partly because we are planning on putting UI there that might only be accessible from that page (and the user might never see if we imported an existing profile and automatically changed it), and partly because we are working on branding our cloud strategy as Firefox Home. We are in the process of submitting an iPhone app called Firefox Home that will in the future have similar functionality to the desktop Home Tab, etc.

(In reply to comment #18) > Best person to talk to is Limi. Thanks. Will do. (In reply to comment #18) > Something we've been thinking about is > slightly altering the concept of Home in Firefox 4. If the user has a home > page (or pages) that are not the default Firefox Start page, we were thinking > about exposing these as app tabs (although with full chrome). So this way the > previous concept of "home page" really means what app tab gets shown on launch. Aren't you afraid this will cause users to get confused? I mean, not new users, or users with a clean profile, but users that have their Firefox 3.6 all set up as they want. App Tabs are tabs that are hard to close by design, and some users will not like that. In the end, it's going to be what it's going to be, but I believe we should keep the old functionality in (from my understanding, it's not hard at all to keep it), so the update doesn't "break" anyone's Firefox. My concept was really just an attempt at solving that problem with ease and efficiency, both in terms of interface and implementation. I'm all for the new behavior, and it should be the default, but it shouldn't override previous configurations. Multiple home pages are the only issue, I think, so we can target those systematically and cleanly, without worrying too much about the consequences in other features. (In reply to comment #18) > The user can still > remove the Firefox Home tab, but we don't want the home tab to be too easy to > override. This is partly because we are planning on putting UI there that > might only be accessible from that page (and the user might never see if we > imported an existing profile and automatically changed it), and partly because > we are working on branding our cloud strategy as Firefox Home. We are in the > process of submitting an iPhone app called Firefox Home that will in the future > have similar functionality to the desktop Home Tab, etc. So if I understand correctly, the plan is not to allow the user to change the place of the home tab? I think that's acceptable enough... However, there's a shedload of design issues that arise from some home tab mockups I've seen. First of all, there's the question of whether or not we should make it chromeless (I've made a post about it here: http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/0dd173f268a16f34# ). In a nutshell, not showing Firefox main UI to the user in the very first page that he sees is very VERY dangerous. Just see Horlander's mockup (attachment to this bug) and you'll see what I mean. That particular interface is, I'm certain, completely impossible. Secondly, making the Home Tab always there (and not taking into account multiple home pages and BarTab-like functionality) will, as you say, significantly change how the user works with its browser. Since it's not possible to close it, users who close their home page after browsing it a bit will need to be taught how to change their settings to fit their browsing habits. This is a relatively confined issue, so it should be relatively simple to address (considering we will probably need a prefs panel overhaul). And then there's the issue of what we actually want AppTabs to stand for. It should be made clear that AppTabs are not necessarily for usually visited sites, but rather for sites we have always open (which are no more than one or two for most users). This concept doesn't really overlap with the concept of Home Pages. My opinion is probably not very relevant, but I think the best course of action is: - really flesh out the about:home page, make it the default and sole home page, in the home tab; - discontinue the notion of Home Button, since it's mostly irrelevant these days, because it's little more than a bookmark; - make custom home pages appear in full tabs, as they do with 3.6, at browser startup (if configured to do so, of course - and we need to remember those users who have home page(s) set but have the browser start with a blank page), and make them fully functional, as they are now; - change the pref panel for "home page" and merge it with "startup", make home pages more like the startup programs in an operating system: allow the user to select multiple startup pages and select whether they run on an AppTab or on a normal tab. I think this (my proposal) should cover most grounds and should work perfectly for all users. I don't know how you feel about that (aka what do you think?). And at the end of the day, we still have the Bookmarks Tab and the prominent issue of giving consistent and easy bookmark access to the user, at all times (as I said in the link I gave above, I think all tabs, except for in-content UI tabs, should have Firefox main toolbar. Maybe we'll want to allow the user to hide it, but not hide it by default).

On a related note, I guess I should also say that this "startup pages" concept is more in tune with l10n, I think. At least in Portuguese, "Home Pages" is translated into "Páginas Iniciais", which reads as "Startup Pages", so it's great! We have the home tab, and we have the startup pages! I think it's a wonderful idea :D *walks away all cocky and overconfident*

I posted a thread about this at mozilla.dev.usability: http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/f1833c54aa6d64f9# Let's discuss things there :)

(In reply to comment #0) > This will be the introduction of the Home Tab. In the future enhancements will > include making a locally hosted page with access to history, add-ons, > bookmarks, etc. Opening up possibilities for creating a user centric home page. Looks like extension New Tab King has done some work in this area: http://www.newtabking.com/learnmore.php https://addons.mozilla.org/en-US/firefox/addon/10828/

Couldn't the home button just be styled like the hometab when it's placed in the nav toolbar?

(In reply to comment #23) > Couldn't the home button just be styled like the hometab when it's placed in > the nav toolbar? This would falsely indicate that you could switch to the home "tab" when it would in fact replace the current page.

So, now, that about:home has landed, when will Home Tab itself land?

Sorry, but i want to ask something as well, are you trying to make Home Tab hard to close like App Tab or Cannot be closed at all?

Home Taqb is "just" another AppTab.

(In reply to comment #27) > Home Taqb is "just" another AppTab. Wrong. The plan's to basically have this hometab replace the home button. It won't be an apptab in the sense that you can open and close it. It'll just be...there. To remove it, you'll have to remove the button from the toolbar.

According to comment 18, it's not just another AppTab. Shall I quote? "If the user has a home page (or pages) that are not the default Firefox Start page, we were thinking about exposing these as app tabs (although with full chrome). [...] These app tabs will have the favicons for the sites." "The user can still remove the Firefox Home tab, but we don't want the home tab to be too easy to override. This is partly because we are planning on putting UI there that might only be accessible from that page (and the user might never see if we imported an existing profile and automatically changed it), and partly because we are working on branding our cloud strategy as Firefox Home."

Ask yourself why is HT and AT in the same meta bug. Certainly it isn't because they are different things. Both HT and AT will have very similiar behaviour.

They are similar but not the same, but there is no point arguing about this. Anyway, I am somewhat even more confused about the status of the Home Tab now. The Target Milestone is set to "Future". Does that means Home Tab will only land after Firefox 4?

My appologize, my first comment indeed sounds like HT and AT are the same. But as Jason had pointed out, the are similiar, not the same. Jason, ther are two HT. One is simple HT, which will be in FX4. The second one is advanced HT, which will be in post FX4.

actually at this point we are differentiating between a home tab (as an app tab), and a locally hosted home page (similar to the current home page but no network connection). This has implications for some of our application level notifications, but either way the long term plan is to have the home app tab.

(In reply to comment #33) > actually at this point we are differentiating between a home tab (as an app > tab), and a locally hosted home page (similar to the current home page but no > network connection). This has implications for some of our application level > notifications, but either way the long term plan is to have the home app tab. Yes — see https://wiki.mozilla.org/Firefox/Projects/UX_Priorities#App_tabs for the breakdown. If we can get someone to own the Home tab part of it, that would be great. It's probably not going to block the release if we don't, however.

isn't the Home Tab a high priority feature wanted for Firefox 4? why is it now not blocking release?

As I understand, HT isn't affected by feature-freeze, about:home was. HT is basicaly theme related work.

(In reply to comment #35) > isn't the Home Tab a high priority feature wanted for Firefox 4? why is it now > not blocking release? I think they may be gonna ditch it unless every1 gets this done asap.

If I'm understanding this right could this not be done with Iframe or the Object element setting a setting in the pref box toggling an option to direct to a page like about:homemain and if not toggled it directed to what ever url is the home page.

(In reply to comment #35) > isn't the Home Tab a high priority feature wanted for Firefox 4? why is it now > not blocking release? It is currently not listed as a blocker for the release. Opportunistic patches still welcome, of course!

Shouldn't it be wanted+ ? ;-)

Is there a reason a simple patch wasn't made to make this behave like the new tab button (become a tab when placed in the tab bar). This can already be placed in the tab bar, it just doesn't change its appearance. This just seems like a glaring omission from the Firefox 4 mockups (though I do understand matching the mockups isn't the entire goal). And I might be missing something that makes this more difficult then that

(In reply to comment #41) > Is there a reason a simple patch wasn't made to make this behave like the new > tab button (become a tab when placed in the tab bar). > > This can already be placed in the tab bar, it just doesn't change its > appearance. > > This just seems like a glaring omission from the Firefox 4 mockups (though I do > understand matching the mockups isn't the entire goal). And I might be missing > something that makes this more difficult then that Yeah, there are some interesting edge cases that we'd have to address — if you enter a URL into the URL bar — it should open in a new window, it probably needs to clear the value, and several other similarly small-but-necessary fixes. I personally agree that it was scoped out of the release plans too early (ie. I think the risk was manageable), but we're picking up most of the home tab and app tabs work that didn't make the cut for our next release (Firefox 5), which should be a small, focused release that should ship 3-6 months after FF4 — at least that's the current release goal.

Is there a reason it can't act as a simple button (creating a new tab on press) versus actually switching to a home tab? This would be no different in behaviour then the new tab button.

The about:home page now opens searches in new tabs. This should be done only when it is opened in a Home Tab.

Back-out this changes please, it's unnecessary and messing up UX. Push it to UX only when you finish

(In reply to Nguyen Bat Hung from comment #45) > Back-out this changes please, it's unnecessary and messing up UX. Push it to > UX only when you finish The whole point of the UX branch is to land experimental changes before they are finished. https://wiki.mozilla.org/UX_Branch If you can't handle that, don't run the UX branch.

Dragging an external file should not overwrite Home Tab (maybe any App tab?, Bug 598587). Middle click should not close Home Tab, nor should it be unpinned/dragged like other tabs.

I landed this on the UX branch for people to test. Frank and Paul, asking you for feedback just to get some fresh eyes on this (and you guys know stuff about tabs, app tabs, and session restore). This patch depends on the patch in bug 692339, and it just adds a home tab (basically just pinned about:home) to every window, and it gets rid of the home button. This patch does not deal with home pages (we can do that in bug 585316), and it does not change the contents of about:home (we should do that piece by piece in separate bugs). I think it's big enough, and I'd like to avoid scope creep.

Comment on attachment 569550 [details] [diff] [review] WIP patch Yay, home tab! :) I haven't read the whole thing yet, but I did notice this: > -let leftmostTab = draggedTab.pinned ? tabs[0] : tabs[numPinned]; > +let leftmostTab = draggedTab.pinned ? this.tabbrowser._homeTabExists : tabs[numPinned]; `leftmostTab` is supposed to be a tab, not an index. `tabs[this.tabbrowser._homeTabExists]` should work. Tab animations are almost surely going to be backed out this or next week, so this section will probably be removed for a while, but it will be needed when animations re-land. :P I'll write more feedback when I finish reading it.

Comment on attachment 569550 [details] [diff] [review] WIP patch Unfortunately, this patch broke detaching tabs and restoring multiple windows correctly, and it doesn't open a new tab for searches from about:home, which enables the home tab to be overwritten. > + if (uriToLoad) { > + gBrowser.addTab(uriToLoad); uriToLoad isn't always a string. This assumption broke detaching tabs. See the comment about window.arguments[0] in BrowserStartup(). Restoring multiple windows has very complex code paths. I haven't completely grasped everything that happens, but the easy way to avoid breakage is to postpone the creation of the home tab until the restoring tabs are created. See changes to aboutHome.js for my search and snippet workarounds. In a production-quality patch, we need something more robust that will even redirect the setting of window.location.href to a new tab. I pushed a patch to try to fix these breakages here: https://hg.mozilla.org/projects/ux/rev/490d519e3c3b Home Tab sure touches a lot of stuff. Thanks for all your work on this! :)

(In reply to Frank Yan (:fryn) from comment #50) > Restoring multiple windows has very complex code paths. I haven't completely > grasped everything that happens, but the easy way to avoid breakage is to > postpone the creation of the home tab until the restoring tabs are created. Yeah, I think we'll want Paul's help here. My patch in bug 692339 changed the way we do window startup to ensure we get blank windows in BrowserStartup, but yeah, session restore is tricky. Postponing the creation of the home tab is probably a good compromise for now, but a real solution would probably be fixing the way we do session restore. There are still checks in there to see if we're overwriting a homepage, which should probably be removed now. If possible, I'd like for us to remove some of what makes session restore complicated, rather than throw more dependent logic on top of it (although we could do that in a follow-up to avoid getting stalled). > See changes to aboutHome.js for my search and snippet workarounds. > In a production-quality patch, we need something more robust that will even > redirect the setting of window.location.href to a new tab. Oops, yeah, I had that at some point and lost it. > I pushed a patch to try to fix these breakages here: > https://hg.mozilla.org/projects/ux/rev/490d519e3c3b Wow, thanks for working on this! I can fold these changes into my patch. > Home Tab sure touches a lot of stuff. Thanks for all your work on this! :) Thanks for taking a look at this. I think my brain started to get fried from all these changes all over the place :)

I updated the patch to include the changes Frank made on the UX branch, including the ones that fixed the bitrot after the tab drag/drop patch was backed out. I also made a fix to handle the History->Home menuitem, but maybe we want to rip that out? However, there are also other things that call that BrowserHome/BrowserGoHome command, so I think that should just go in a follow-up.

(In reply to Margaret Leibovic [:margaret] from comment #52) > Created attachment 570075 [details] [diff] [review] [diff] [details] [review] > WIP v2 Some initial feedback: > I also made a fix to handle the History->Home menuitem, but maybe we want to > rip that out? However, there are also other things that call that > BrowserHome/BrowserGoHome command, so I think that should just go in a > follow-up. If we're going to remove the home button and eliminate the concept of having a set of home pages open on browser startup, then I think these fixes should be included. We shouldn't do a halfway change for this. > + // Open links from home tab in new tabs. > + if (linkNode.ownerDocument.documentURIObject.spec == "about:home") > + return "_blank"; Nifty. Is there a way to prevent that tab's URL from being changed at all? Maybe a chrome-privileged unload handler? I want to prevent third-party code, e.g. add-ons, etc., from breaking it. > + if (that.childElementCount == 1 && that.tabbrowser._homeTabExists) > + that.tabbrowser.removeCurrentTab(); Since it might not be obvious what this does, I suggest prefixing this with a comment explaining that we close the window when the home tab is the only tab left.

(In reply to Frank Yan (:fryn) from comment #53) > > I also made a fix to handle the History->Home menuitem, but maybe we want to > > rip that out? However, there are also other things that call that > > BrowserHome/BrowserGoHome command, so I think that should just go in a > > follow-up. > > If we're going to remove the home button and eliminate the concept of having > a set of home pages open on browser startup, then I think these fixes should > be included. We shouldn't do a halfway change for this. Okay, I just got rid of that stuff. > > + // Open links from home tab in new tabs. > > + if (linkNode.ownerDocument.documentURIObject.spec == "about:home") > > + return "_blank"; > > Nifty. Is there a way to prevent that tab's URL from being changed at all? > Maybe a chrome-privileged unload handler? > I want to prevent third-party code, e.g. add-ons, etc., from breaking it. At one point I played around with annotating docShell so that you couldn't navigate within the tab, but that was bad because there wasn't any feedback about why the tab wasn't navigating. I think it might be scope creep to worry about third-party code right now. Sounds like follow-up material to me. > > + if (that.childElementCount == 1 && that.tabbrowser._homeTabExists) > > + that.tabbrowser.removeCurrentTab(); > > Since it might not be obvious what this does, I suggest prefixing this with > a comment explaining that we close the window when the home tab is the only > tab left. I just copied this from you. Care to specify what your comment would be? :)

(In reply to Margaret Leibovic [:margaret] from comment #54) > > > + if (that.childElementCount == 1 && that.tabbrowser._homeTabExists) > > > + that.tabbrowser.removeCurrentTab(); > > > > Since it might not be obvious what this does, I suggest prefixing this with > > a comment explaining that we close the window when the home tab is the only > > tab left. > > I just copied this from you. Care to specify what your comment would be? :) // Close the other window if the home tab is its only remaining tab. --- Also, we need to update _blurTab to switch to a different tab group if there are other tab groups but no more unpinned tabs in the current group, but since it's Panorama-only, we can leave that to a followup. ;)

(In reply to Frank Yan (:fryn) from comment #55) > Also, we need to update _blurTab to switch to a different tab group if there > are other tab groups but no more unpinned tabs in the current group, but > since it's Panorama-only, we can leave that to a followup. ;) That actually seems like a bug that's independent of the home tab, since right now you can end up in a tab group with only pinned tabs and no other tabs. We can file a panorama bug about that if there isn't one already (although as a panorama user, I actually don't mind when I end up with an empty tab group, since usually that happens right before I start a new task in the tab group anyway </digression>).

So, I broke down my patch into a bunch of smaller patches to try to make this more manageable. Bear with me as I upload them all!

really hope to see home tab soon. =D

Is hometab in feature list of Firefox 12 ? https://wiki.mozilla.org/Features/Release_Tracking#Firefox_12:_Desktop

Is this bug relevant anymore ?

(In reply to Tim Nguyen [:ntim] from comment #66) > Is this bug relevant anymore ? Yeah, not relevant anymore.