1343278 - Session restore fails partly: correct number of tabs opened, but all are set to "null"

Status: RESOLVED INACTIVE

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

Description

[villeneuve]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

Reopened Firefox after exiting it just via homebutton or by switching to another app.


Actual results:

When reopening Firefox after exiting it just via homebutton or by switching to another app it sometimes fails to properly restore the session. It then has the correct number of tabs open that were opened when exiting Firefox, but the content of the tabs is empty and all tabs are named "null" and when I click one of the tabs it just does a search of the word "null" in the default search-engine.


Expected results:

All the tabs that were open when exiting Firefox should reappear intact when opening Firefox again.

Comment 1

[Jan Henning [:JanH]]

Just to confirm, this is affecting all tabs, even the foreground tab? What is appearing in the URL bar during startup, i.e. does it say "null" as well and does the text in the URL bar remain unchanged during the whole startup, or does it change once the tab actually starts loading (the orange progress bar starts moving)?
What happens if you try long-pressing the back button to try bringing up the history menu on one of those tabs?

> [...] it sometimes fails to properly restore the session.

You're saying "sometimes" - how frequently approximately? If this has happened to you a few times, could you turn on "browser.sessionstore.debug_logging" in about:config and get a log when this happens again?

For retrieving the log you need either a computer with ADB (https://developer.android.com/studio/releases/platform-tools.html) handy - use |adb logcat -dv threadtime | findstr Gecko > filename.log| on the command line, or else you could try installing the LogView addon (https://addons.mozilla.org/android/addon/logview) and use that to get a log if this happens again.

Unfortunately I've no immediate idea what could have gone wrong. I've no idea under what circumstances and how we can open "null" tabs. The fact that we do open the tabs (and the correct number of them) would indicate that the session store file is syntactically valid, otherwise the Java session parser would just throw an exception and skip that tab or even the whole file.

Comment 2

[villeneuve]

Yes, even the foreground tab.
Can't currently tell, what's appearing in the URL bar during startup, but will look for it when the error occurs again.
Long-pressing the back button is configured to kill the foreground app, so I didn't know about that function in Firefox until now. I'll reconfige the back-button to default behavior now.

Defining "sometimes": Difficult to tell, every one or two month.

I now turned on "browser.sessionstore.debug_logging".

I'll report here once the error occurs again.

Comment 3

[villeneuve]

So I updated to Firefox 52.0.1 from 50 and I noticed that the session restore mechanism must've been reworked between the version because the general behavior when recovering a session is different (not talking about bugs here).

For the first time since I created this bugreport today the bug occured after opening Firefox after my smartphone had done a sudden reboot with the only difference to my initial report in the result being that the last opened/active tab was restored properly, but all the other tabs show "null bei DuckDuckGo" (I'm running German language, so I guess in Englisch it would be "null at DuckDuckGo").

Comment 4

[villeneuve]

I attached the log about:logs gave me!

Comment 5

[villeneuve]

Attachment: logfile after failed session restore

Comment 6

[villeneuve]

I just wanted to try and see what happens when I long-press the backbutton of my smartphone on one of the "null-tabs" as suggested: When I changed from the successfully restored foreground-tab to one of the failed "null-tabs" it doesn't show the result page of my default searchengine for a search of the word "null" as it did before, but instead it shows as if the tab is still loading with the orange progress bar 3 quarters full, but stuck there forever. At the same time though the tab-preview thumbnails in the opened tabs overview show the correct thumbnail, in this case DuckDuckGo's site that's saying I'm being redirected to the non-JavaScript site, which is correct since I have NoScript installed and had it set to JavaScript disabled when my smartphone did the automatic reboot.
Even when I press the X-button to cancel loading of the page nothing happens, the progress bar stays visible. I have to click the adressbar and then the "Go"-button on the keyboard to make the tab load the website. Long-pressing the back button does nothing though while it works on the successfully restored tab!

Comment 7

[villeneuve]

I just noticed, that my overall history not only shows all the URLs that were in the lost tabs, but also lists them as being visited yesterday (the failed session restore was yesterday shortly before midnight). If I remember correctly the visited-timestamp of a URL only gets updated when it gets viewed in the foreground tab, but it certainly wasn't me visiting those URLs yesterday. So to me it looks like the session restore actually does restore all the tabs correctly at first but immediately afterwards something goes wrong creating these "null-tabs".

Comment 8

[Jan Henning [:JanH]]

Thank for the effort, but unfortunately the log doesn't show the actual startup itself.

I don't remember any major changes in session restoring and the big restructuring of message passing between Gecko and the UI (bug 1317604) only happened starting from Firefox 53 - although of course some more subtle changes might be possible.

(In reply to villeneuve from comment #6)
> I just wanted to try and see what happens when I long-press the backbutton
> of my smartphone on one of the "null-tabs" as suggested: When I changed from
> the successfully restored foreground-tab to one of the failed "null-tabs" it
> doesn't show the result page of my default searchengine for a search of the
> word "null" as it did before, but instead it shows as if the tab is still
> loading with the orange progress bar 3 quarters full, but stuck there
> forever.

Hmm, normally everything but the foreground tab isn't even really loaded on startup - we just create a tab object that holds the previous session history data and restore it (and actually start loading the correct URL) only when selected. So if the progress bar was showing 60 or 80 % progress (compare https://dxr.mozilla.org/mozilla-central/rev/ce69b6e1773e9e0d0a190ce899f34b1658e66ca4/mobile/android/base/java/org/mozilla/gecko/Tab.java#111) the moment you switched to it, this seems to indicate that in the meantime somebody else touched that tab and caused something to start loading.

> Even when I press the X-button to cancel loading of the page nothing
> happens, the progress bar stays visible. I have to click the adressbar and
> then the "Go"-button on the keyboard to make the tab load the website.

Which means we do have a tab object on the Gecko side (otherwise loading anything in that tab wouldn't work at all, compare bug 1356563), only in an unknown state.

(In reply to villeneuve from comment #7)
> I just noticed, that my overall history not only shows all the URLs that
> were in the lost tabs, but also lists them as being visited yesterday (the
> failed session restore was yesterday shortly before midnight). If I remember
> correctly the visited-timestamp of a URL only gets updated when it gets
> viewed in the foreground tab, but it certainly wasn't me visiting those URLs
> yesterday. So to me it looks like the session restore actually does restore
> all the tabs correctly at first but immediately afterwards something goes
> wrong creating these "null-tabs".

That's strange, because
- as I said above, only the foreground tab is actually loaded. All other tabs are created as delay-loaded "zombie" tabs only.
- in my experience, tabs loading after being restored from session store data (including both the foreground tab that immediately starts loading as soon as you start Firefox, as well as any background tabs that are restored when you switch to them) don't generate new history entries. If you want a new history entry, you need to manually reload the page.

So it seems like something is touching all those background tabs on startup - maybe it's one of the add-ons you're using?

If you're willing to try another attempt at getting a log, please also set "consoleservice.logcat" to true, so any potential JS errors that get logged to the browser console appear in the logcat as well, and try getting the log as soon as possible after startup, before it gets overwritten.

Comment 9

[sascha.zenglein]

I can confirm this bug. With the exception that my history shows multiple "about:home" tabs under recently closed tabs. I will also turn on logging now.


This is really annoying if you have many tabs open and can't remember them all.

Comment 10

[Firefox Bug Husbandry Bot]

Closing per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Contact :susheel if you think this bug should be re-opened