Last Comment Bug 544819 - Create a basic Home Tab linking to the current Home Page
: Create a basic Home Tab linking to the current Home Page
Status: RESOLVED INVALID
:
Product: Firefox
Classification: Client Software
Component: Theme (show other bugs)
: unspecified
: All All
: -- enhancement with 33 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://wiki.mozilla.org/Features/Des...
: 563734 (view as bug list)
Depends on: 692339 563723
Blocks: 551849 580046
  Show dependency treegraph
 
Reported: 2010-02-07 21:07 PST by Stephen Horlander [:shorlander]
Modified: 2014-11-07 08:44 PST (History)
86 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
[Mockup] Home Tab (287.57 KB, image/png)
2010-02-07 21:07 PST, Stephen Horlander [:shorlander]
no flags Details
[Mockup] Preferences screen relating to multiple home pages (1.08 MB, image/jpeg)
2010-06-02 08:53 PDT, Tiago Sá
no flags Details
WIP patch (42.16 KB, patch)
2011-10-25 17:00 PDT, :Margaret Leibovic
fryn: feedback-
Details | Diff | Splinter Review
WIP v2 (44.86 KB, patch)
2011-10-27 13:52 PDT, :Margaret Leibovic
no flags Details | Diff | Splinter Review
[Part 1] - Add home tab (14.16 KB, patch)
2011-10-28 15:45 PDT, :Margaret Leibovic
no flags Details | Diff | Splinter Review
[Part 2] - Make sure session restore doesn't remember home tab (4.50 KB, patch)
2011-10-28 15:46 PDT, :Margaret Leibovic
no flags Details | Diff | Splinter Review
[Part 3] - Don't overwrite the home tab (3.99 KB, patch)
2011-10-28 15:46 PDT, :Margaret Leibovic
no flags Details | Diff | Splinter Review
[Part 4] - Kill the home button and home menuitem (16.65 KB, patch)
2011-10-28 15:47 PDT, :Margaret Leibovic
no flags Details | Diff | Splinter Review
[Part 5] - Get rid of homepage preferences (13.19 KB, patch)
2011-10-28 15:47 PDT, :Margaret Leibovic
no flags Details | Diff | Splinter Review
[Part 6] - Change the about:home favicon (7.51 KB, patch)
2011-10-28 15:48 PDT, :Margaret Leibovic
no flags Details | Diff | Splinter Review
[Part 7] - Home tab tests (3.37 KB, patch)
2011-10-28 15:48 PDT, :Margaret Leibovic
no flags Details | Diff | Splinter Review

Description Stephen Horlander [:shorlander] 2010-02-07 21:07:09 PST
Created attachment 425751 [details]
[Mockup] Home Tab

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.
Comment 2 Stephen Horlander [:shorlander] 2010-02-07 22:43:44 PST
(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.
Comment 3 Paul [pwd] 2010-04-28 08:10:18 PDT
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.
Comment 4 d 2010-04-28 08:12:04 PDT
(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?
Comment 5 Paul [pwd] 2010-04-28 08:16:54 PDT
(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.
Comment 6 Alex Faaborg [:faaborg] (Firefox UX) 2010-04-28 11:33:40 PDT
Home tabs and app tabs are still targeted for 4.0
Comment 7 Marco Bonardo [::mak] (Away 6-20 Aug) 2010-05-04 12:01:18 PDT
*** Bug 563734 has been marked as a duplicate of this bug. ***
Comment 8 Tommy XP 2010-05-23 02:45:56 PDT
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.
Comment 9 David [:auscompgeek] 2010-05-23 20:29:07 PDT
(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.
Comment 10 Tommy XP 2010-05-24 02:25:35 PDT
(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.
Comment 11 Peter Henkel [:Terepin] 2010-05-24 04:11:43 PDT
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.
Comment 12 Tommy XP 2010-05-24 22:25:24 PDT
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.
Comment 13 Peter Henkel [:Terepin] 2010-05-24 23:31:54 PDT
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.
Comment 14 Tiago Sá 2010-06-02 08:50:08 PDT
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!-
Comment 15 Peter Henkel [:Terepin] 2010-06-02 08:52:41 PDT
Since when is Firefox capable of handling multiple homepages?
Comment 16 Tiago Sá 2010-06-02 08:53:21 PDT
Created attachment 448759 [details]
[Mockup] Preferences screen relating to multiple home pages

This is the mockup I promised in my comment above.
Comment 17 Tiago Sá 2010-06-02 08:54:58 PDT
(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.
Comment 18 Alex Faaborg [:faaborg] (Firefox UX) 2010-06-02 11:10:24 PDT
>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.
Comment 19 Tiago Sá 2010-06-02 11:43:28 PDT
(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).
Comment 20 Tiago Sá 2010-06-02 12:11:10 PDT
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*
Comment 21 Tiago Sá 2010-06-03 06:58:39 PDT
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 :)
Comment 22 [not reading bugmail] 2010-07-05 23:58:18 PDT
(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/
Comment 23 imradyurrad 2010-07-23 13:57:49 PDT
Couldn't the home button just be styled like the hometab when it's placed in the nav toolbar?
Comment 24 Dão Gottwald [:dao] 2010-07-24 03:03:35 PDT
(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.
Comment 25 Peter Henkel [:Terepin] 2010-08-28 04:40:41 PDT
So, now, that about:home has landed, when will Home Tab itself land?
Comment 26 Tan Wei Lin Jason [:Ryuji] 2010-08-29 09:53:31 PDT
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?
Comment 27 Peter Henkel [:Terepin] 2010-08-30 04:40:06 PDT
Home Taqb is "just" another AppTab.
Comment 28 imradyurrad 2010-08-30 04:43:47 PDT
(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.
Comment 29 Tiago Sá 2010-08-30 04:48:39 PDT
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."
Comment 30 Peter Henkel [:Terepin] 2010-08-30 04:55:09 PDT
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.
Comment 31 Tan Wei Lin Jason [:Ryuji] 2010-08-31 06:13:49 PDT
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?
Comment 32 Peter Henkel [:Terepin] 2010-08-31 09:27:59 PDT
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.
Comment 33 Alex Faaborg [:faaborg] (Firefox UX) 2010-08-31 17:56:12 PDT
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.
Comment 34 Alex Limi (:limi) — Firefox UX Team 2010-08-31 18:05:40 PDT
(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.
Comment 35 Tan Wei Lin Jason [:Ryuji] 2010-09-01 07:04:24 PDT
isn't the Home Tab a high priority feature wanted for Firefox 4? why is it now not blocking release?
Comment 36 Peter Henkel [:Terepin] 2010-09-01 07:07:08 PDT
As I understand, HT isn't affected by feature-freeze, about:home was. HT is basicaly theme related work.
Comment 37 Wyatt Childers 2010-09-17 17:01:55 PDT
(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.
Comment 38 Wyatt Childers 2010-09-17 17:04:05 PDT
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.
Comment 39 Alex Limi (:limi) — Firefox UX Team 2010-09-20 23:43:17 PDT
(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!
Comment 40 Nicolas Mandil (:NicolasWeb) 2010-09-21 01:43:52 PDT
Shouldn't it be wanted+ ? ;-)
Comment 41 andrew 2011-01-20 13:30:02 PST
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
Comment 42 Alex Limi (:limi) — Firefox UX Team 2011-01-20 13:58:52 PST
(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.
Comment 43 andrew 2011-01-21 18:04:03 PST
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.
Comment 44 Siddhartha Dugar [:sdrocking] 2011-09-22 02:42:16 PDT
The about:home page now opens searches in new tabs. This should be done only when it is opened in a Home Tab.
Comment 45 Nguyen Bat Hung 2011-09-24 03:47:03 PDT
Back-out this changes please, it's unnecessary and messing up UX. Push it to UX only when you finish
Comment 46 Frank Yan (:fryn) 2011-09-24 03:52:35 PDT
(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.
Comment 47 Siddhartha Dugar [:sdrocking] 2011-09-24 04:40:30 PDT
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.
Comment 48 :Margaret Leibovic 2011-10-25 17:00:24 PDT
Created attachment 569550 [details] [diff] [review]
WIP patch

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 49 Frank Yan (:fryn) 2011-10-26 00:09:28 PDT
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 50 Frank Yan (:fryn) 2011-10-26 05:53:42 PDT
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! :)
Comment 51 :Margaret Leibovic 2011-10-26 09:08:03 PDT
(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 :)
Comment 52 :Margaret Leibovic 2011-10-27 13:52:42 PDT
Created attachment 570075 [details] [diff] [review]
WIP v2

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.
Comment 53 Frank Yan (:fryn) 2011-10-27 16:30:23 PDT
(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.
Comment 54 :Margaret Leibovic 2011-10-27 17:19:56 PDT
(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? :)
Comment 55 Frank Yan (:fryn) 2011-10-27 17:27:35 PDT
(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. ;)
Comment 56 :Margaret Leibovic 2011-10-28 11:25:58 PDT
(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>).
Comment 57 :Margaret Leibovic 2011-10-28 15:45:21 PDT
Created attachment 570387 [details] [diff] [review]
[Part 1] - Add home tab

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!
Comment 58 :Margaret Leibovic 2011-10-28 15:46:09 PDT
Created attachment 570389 [details] [diff] [review]
[Part 2] - Make sure session restore doesn't remember home tab
Comment 59 :Margaret Leibovic 2011-10-28 15:46:45 PDT
Created attachment 570391 [details] [diff] [review]
[Part 3] - Don't overwrite the home tab
Comment 60 :Margaret Leibovic 2011-10-28 15:47:11 PDT
Created attachment 570392 [details] [diff] [review]
[Part 4] - Kill the home button and home menuitem
Comment 61 :Margaret Leibovic 2011-10-28 15:47:40 PDT
Created attachment 570393 [details] [diff] [review]
[Part 5] - Get rid of homepage preferences
Comment 62 :Margaret Leibovic 2011-10-28 15:48:08 PDT
Created attachment 570395 [details] [diff] [review]
[Part 6] - Change the about:home favicon
Comment 63 :Margaret Leibovic 2011-10-28 15:48:43 PDT
Created attachment 570396 [details] [diff] [review]
[Part 7] - Home tab tests
Comment 64 chaosfreedom1220 2011-10-31 21:34:27 PDT
really hope to see home tab soon. =D
Comment 65 bogas04 2012-02-01 00:49:45 PST
Is hometab in feature list of Firefox 12 ? https://wiki.mozilla.org/Features/Release_Tracking#Firefox_12:_Desktop
Comment 66 Tim Nguyen :ntim (use needinfo?) 2014-11-06 14:44:55 PST
Is this bug relevant anymore ?
Comment 67 Stephen Horlander [:shorlander] 2014-11-07 08:44:36 PST
(In reply to Tim Nguyen [:ntim] from comment #66)
> Is this bug relevant anymore ?

Yeah, not relevant anymore.

Note You need to log in before you can comment on or make changes to this bug.