1551095 - Closed tabs reappear when killing Firefox

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Session Restore, defect, P2)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Android 8.1.0; Mobile; rv:66.0) Gecko/66.0 Firefox/66.0

Steps to reproduce:

Using Firefox 66.0.2 on Android 8.1.0, manually closing a set of tabs then killing Firefox (either via Recents or with system's "hold back to kill") the tabs reappear as if never closed by user.

Expected results:

The tabs should stay gone.

Comment 1

[[e-mail]]

To be clear this happens when opening Firefox again (after killing it).

Comment 2

[Jan Henning [:JanH]]

How much time passes between closing the tabs and you killing the app?

The most helpful thing to see what is actually happening would be some logs - do you know how to retrieve them from your phone, or do you need some guidance? In any case you should turn on browser.sessionstore.debug_logging from about:config and restart the browser before gathering any logs.

Comment 3

[Eliza Balazs]

Attachment: tab.txt

Hi!

I tested this on RC 66.0.2 with Nexus 6P (Android 8.1.0) and I could reproduce the issue 1 out of 5 attempts. You can find attached the requested logcat.

This is also reproducible on RC 67.0, Beta 68.0b3, Nightly 68.0a1 (2019-05-17).

Steps to reproduce:

1. Launch Fennec and open 4 pages from Recommended by Pocket;
2. Go to Tab tray and check if the pages are loaded;
3. Close the pages from the Tab tray;
4. Exit Fennec from Task Manager and then reopen it;
5. Observe if the tabs closed and step 3 are restored.

Thanks!

Comment 4

[Jan Henning [:JanH]]

I don't see any log entries for GeckoSessionStore - did you actually turn on browser.sessionstore.debug_logging and restarted the browser once before gathering any logs?

Comment 5

[Eliza Balazs]

Attachment: tab7.txt

Hi!
I haven't change that from about:config when taking the previous logcat.
Here is the one with entries from GeckoSessionStore. I hope this will help.
Thanks!

Comment 7

[Jan Henning [:JanH]]

(In reply to Eliza Balazs from comment #5)

Posted file tab7.txt

The browser is indeed being killed before we've even had a chance to flush the current session state to disk in response to Firefox being backgrounded (because the task switcher is brought into the foreground).
Indeed the same thing can be reproduced with desktop Firefox if you kill/crash the browser immediately after closing some tabs, though admittedly on desktop operating systems closing the browser by killing it isn't supposed to be a common operation, whereas on Android it can happen more commonly for better or for worse.

Given that we don't want to thrash the disk either by writing every little change separately, I'm not sure there's a good solution here, though, especially one that doesn't involve more invasive changes with a corresponding risk of regressions.

Maybe we could unconditionally trigger the state saving during onSaveInstanceState instead of waiting for onApplicationBackground, which might give us a little more time to try writing the session before the user manages to kill us, but I need to think a little more about whether that change might be safe to do...

Otherwise, the least invasive workaround would be making the "Quit" menu item in our main menu permanently visible again [1] in order to give us a chance to properly save the current state of the browsing session before shutting down if users quit Firefox via the "Quit" button instead of effectively killing us straightaway.

[1] At the moment this menu item is only shown under a limited amount of circumstances, the likely most common of which would be having one or more of the "Clear data on shutdown" options active.

Comment 8

[Jan Henning [:JanH]]

(In reply to Jan Henning [:JanH] from comment #7)

Maybe we could unconditionally trigger the state saving during onSaveInstanceState instead of waiting for onApplicationBackground, which might give us a little more time to try writing the session before the user manages to kill us, but I need to think a little more about whether that change might be safe to do...

Actually scratch that - via the GeckoActivityMonitor, we are in fact already doing that.

Comment 9

[Chris Peterson [:cpeterson]]

Downgrading priority from P1 to P2

Comment 10

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