User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36 Steps to reproduce: Opened an http intent with Firefox for Android Actual results: Firefox for Android showed two tabs open: Firefox Home, and the tab for the intent I opened. Expected results: Firefox for Android should have closed Firefox Home.
Brian - I thought we already tried to stop showing about:home when opening a URL from an external intent. Maybe we regressed? Heath - Does this happen if you make sure Firefox is not running before opening the URL? Try swiping Firefox from the recent apps list to make sure it's not running, then open the URL from an shortcut or external app (how every you did it).
>Does this happen if you make sure Firefox is not running before opening the URL? 1. Swipe from the recent apps list to kill Firefox 2. Launch a link into Firefox from a home screen shortcut (facebook in this case). 3. Observe 2 tabs open: Firefox Home, Facebook
I tried reproducing this across all channels and wasn't able to reproduce. I made sure all browsers were closed and force-stopped, not running. I launched each with a link to a restaurant I had in a card in Google Now. Each browser correctly opened the tab without an about:home tab. WFM.
Can you detail which version you are testing with and which device?
Created attachment 8435816 [details] IMG_1928.MOV Video of the bug. Tested with version 29.0.1 running on a Nexus 5 running Android 4.4.2.
Ah the misinterpretation here is that you're launching a home-screen icon made from Firefox.
Sorry about that. I figured my terminology was wrong. I wish the Firefox Home tab would disappear when it isn't needed. I don't like having extra tabs open, and I constantly think I've left an extra tab hanging around, when in fact it's the Firefox Home tab.
Do you happen to have Always Restore Tabs set in the browser settings? I was only able to reproduce this when using that setting.
Yes! Disabling tab restoration fixes the problem, but of course then my tabs disappear if I quit Firefox. I'll probably leave it disabled for a while until this is resolved.
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
OS: Mac OS X → Android
Hardware: x86 → ARM
Summary: Close Firefox Home tab when another link is open → An about:home tab is automatically restored with Always Restore Tabs enabled when opening Firefox via intent
If Always Restore Tabs is enabled, this seems like the expected behavior to me. Always Restore Tabs essentially makes Firefox act as if it wasn't closed, so the behavior here is consistent with the behavior when opening this shortcut while Firefox is already running.
Ok, so this is a feature request, not a bug. I'd like Firefox home to close if it's the only thing open when another tab opens.
We could change our session restore logic to omit these "placeholder tabs" on restore. A placeholder tab is defined as one that 1) has about:home as its URL, and 2) has no session history. However, doing this in all session restore cases would introduce some inconsistencies for Fennec's background Bundle restore handling. When Fennec is backgrounded, we may or may not be killed by the OS as described in https://wiki.mozilla.org/Mobile/SessionRestore. If we are killed in the background, we should restore the browser to exactly the state it was before being killed (or at least as much as possible) to make this process seamless. Since this restore process uses the same session restore logic, removing placeholder tabs during restore would potentially cause tabs to disappear just from hitting the home button. This doesn't mean we can't still purge these placeholder tabs -- it just means we need to be careful about when we do it. I think it should be safe to omit placeholder tabs for any non-Bundle restore.
Also, I noticed in the video that you tried several times to close that last remaining tab, and it makes me wonder if the ideal UX here would be to allow our tab count to go to zero like Chrome. Then we wouldn't have any special cases for omitting tabs during restore; you could just close every tab, then a single tab would open when you tab the shortcut. Unfortunately, we assume in many places in our code that we always have a (non-null) selected tab, so this change wouldn't be trivial.
That would be ideal, but an option for it to disappear/reappear as needed smoothly would be fine. If I haven't interacted with it at all, it should just close.
Assignee: nobody → bnicholson
QA Contact: bnicholson
Brian - Can you look into a plan for this?
tracking-fennec: ? → +
filter on [mass-p5]
Priority: -- → P5
Assignee: bnicholson → nobody
Status: ASSIGNED → NEW
tracking-fennec: + → ?
Sounds like this is a UX feature request rather than a polish bug. To consider: auto-closing "about:home" tab if the user opens a tab in Firefox from another app. Given that they didn't open a new tab themselves.
No longer blocks: 1157964
Ni-ing Ricardo to think about this flow
Note that with bug 1261008, we've stopped restoring about:home tabs if they contain no session history.
(In reply to Jan Henning [:JanH] from comment #20) > Note that with bug 1261008, we've stopped restoring about:home tabs if they > contain no session history. I'm a bit confused now. JanH, are you saying that this bug and bug 1261008 are mutually exclusive? Or is my understanding in comment 18 incorrect here?
If I'm understanding this bug correctly, it has been fixed by bug 1261008 for the case were Firefox doesn't have any interesting tabs open (only about:home without session history) and has stopped running (either because the user has explicitly quit the app, or because of the low memory killer). In that case session restore will ignore the empty about:home tabs, so we only open the tab received through the intent. The remaining case for this bug is where Firefox has been backgrounded with no interesting tabs, but is still running. In that case session restore doesn't get involved, so we just open a new tab and leave the original about:home tab(s) open.
But as Mfinkle pointed out in comment 1, there should not be an about:home tab if the user is coming in from another app anyways. So as long as that's true, this bug should be a non-issue?
You need to log in before you can comment on or make changes to this bug.