Create a basic Home Tab linking to the current Home Page

RESOLVED INVALID

Status

()

Firefox
Theme
--
enhancement
RESOLVED INVALID
7 years ago
3 years ago

People

(Reporter: shorlander, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs)

unspecified
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(9 attachments, 2 obsolete attachments)

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
Blocks: 544820
(Reporter)

Updated

7 years ago
Blocks: 544821

Comment 1

7 years ago
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
(Reporter)

Comment 2

7 years ago
(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

7 years ago
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

7 years ago
(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

7 years ago
(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

Updated

7 years ago
Duplicate of this bug: 563734

Updated

7 years ago
Blocks: 551849

Updated

7 years ago
Depends on: 563723

Comment 8

7 years ago
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

7 years ago
(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

7 years ago
(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.

Comment 12

7 years ago
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.

Comment 14

7 years ago
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?

Comment 16

7 years ago
Created attachment 448759 [details]
[Mockup] Preferences screen relating to multiple home pages

This is the mockup I promised in my comment above.

Comment 17

7 years ago
(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.

Comment 19

7 years ago
(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

7 years ago
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

7 years ago
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 :)
(Reporter)

Updated

7 years ago
Blocks: 572482
(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/
Blocks: 580046

Comment 23

7 years ago
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.

Comment 28

7 years ago
(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

7 years ago
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.

Comment 37

7 years ago
(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

7 years ago
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+ ? ;-)

Comment 41

6 years ago
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.

Comment 43

6 years ago
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.
Blocks: 675821
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

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

Comment 46

6 years ago
(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.

Updated

6 years ago
Depends on: 692339

Comment 48

6 years ago
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.
Assignee: nobody → margaret.leibovic
Status: NEW → ASSIGNED
Attachment #569550 - Flags: feedback?(paul)
Attachment #569550 - Flags: feedback?(fryn)

Comment 49

6 years ago
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

6 years ago
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! :)
Attachment #569550 - Flags: feedback?(fryn) → feedback-

Comment 51

6 years ago
(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

6 years ago
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.
Attachment #569550 - Attachment is obsolete: true
Attachment #570075 - Flags: feedback?(paul)
Attachment #570075 - Flags: feedback?(fryn)
Attachment #569550 - Flags: feedback?(paul)

Comment 53

6 years ago
(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

6 years ago
(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

6 years ago
(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

6 years ago
(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

6 years ago
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!
Attachment #570075 - Attachment is obsolete: true
Attachment #570075 - Flags: feedback?(paul)
Attachment #570075 - Flags: feedback?(fryn)

Comment 58

6 years ago
Created attachment 570389 [details] [diff] [review]
[Part 2] - Make sure session restore doesn't remember home tab

Comment 59

6 years ago
Created attachment 570391 [details] [diff] [review]
[Part 3] - Don't overwrite the home tab

Comment 60

6 years ago
Created attachment 570392 [details] [diff] [review]
[Part 4] - Kill the home button and home menuitem

Comment 61

6 years ago
Created attachment 570393 [details] [diff] [review]
[Part 5] - Get rid of homepage preferences

Comment 62

6 years ago
Created attachment 570395 [details] [diff] [review]
[Part 6] - Change the about:home favicon

Comment 63

6 years ago
Created attachment 570396 [details] [diff] [review]
[Part 7] - Home tab tests

Comment 64

6 years ago
really hope to see home tab soon. =D

Updated

6 years ago
No longer blocks: 675821

Updated

6 years ago
No longer blocks: 544820, 544821, 572482

Updated

5 years ago
Assignee: margaret.leibovic → nobody
Status: ASSIGNED → NEW

Comment 65

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

Comment 66

3 years ago
Is this bug relevant anymore ?
Flags: needinfo?(shorlander)
(Reporter)

Comment 67

3 years ago
(In reply to Tim Nguyen [:ntim] from comment #66)
> Is this bug relevant anymore ?

Yeah, not relevant anymore.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(shorlander)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.