1021695 - An about:home tab is automatically restored with Always Restore Tabs enabled when opening Firefox via intent

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect, P5)

Description

[Heath Borders]

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.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

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).

Comment 2

[Heath Borders]

>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

Comment 3

[Aaron Train [:aaronmt]]

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.

Comment 4

[Aaron Train [:aaronmt]]

Can you detail which version you are testing with and which device?

Comment 5

[Heath Borders]

Attachment: IMG_1928.MOV

Video of the bug. Tested with version 29.0.1 running on a Nexus 5 running Android 4.4.2.

Comment 6

[Aaron Train [:aaronmt]]

Ah the misinterpretation here is that you're launching a home-screen icon made from Firefox.

Comment 7

[Heath Borders]

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.

Comment 8

[Aaron Train [:aaronmt]]

Do you happen to have Always Restore Tabs set in the browser settings? I was only able to reproduce this when using that setting.

Comment 9

[Heath Borders]

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.

Comment 10

[Aaron Train [:aaronmt]]

Re-summarizing.

Comment 11

[Brian Nicholson (:bnicholson)]

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.

Comment 12

[Heath Borders]

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.

Comment 13

[Brian Nicholson (:bnicholson)]

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.

Comment 14

[Brian Nicholson (:bnicholson)]

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.

Comment 15

[Heath Borders]

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.

Comment 16

[Mark Finkle (:mfinkle) (use needinfo?)]

Brian - Can you look into a plan for this?

Comment 17

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]

Comment 18

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

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.

Comment 19

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Ni-ing Ricardo to think about this flow

Comment 20

[Jan Henning [:JanH]]

Note that with bug 1261008, we've stopped restoring about:home tabs if they contain no session history.

Comment 21

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(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?

Comment 22

[Jan Henning [:JanH]]

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.

Comment 23

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

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?

Comment 24

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.