1662400 - Creating new GeckoSession and restoring SessionState from other, closed GeckoSession creates non-interactive white page

Status: RESOLVED FIXED

(GeckoView :: General, defect)

Description

[Sebastian Kaspari (:sebastian; :pocmo)]

We have multiple scenarios where we close a GeckoSession, keep its last SessionState around and later restore it into a new GeckoSession. For example:

• (1) When closing a tab, we keep the SessionState to support "undo", where we will create a new GeckoSession and restore.
• (2) When the content process crashes or gets killed we keep the last SessionState of affected GeckoSession around and close the GeckoSession. When needed we will lazily recreate a GeckoSession and restore the state. (This is the new behavior in development, replacing our previous code that tried to always immediately restore everything).

What we are seeing with at least GeckoView Nightly is that this often results in a white page. This page is completely not interactive and it's also not possible to load any new URLs etc.

In https://github.com/mozilla-mobile/fenix/issues/14459 Emily sees this happening for case (1) after recreating a tab that we closed previously.

I am running into the same problem with the reimplemented crash handling (case 2) in https://github.com/mozilla-mobile/android-components/issues/8255. On crash we close the affected GeckoSession and keep the SessionState. When the user decides to restore the tab then we create a new session and restore the state. For me this will always create this white zombie tab. Weirdly I only see this happening in Fenix while everything's looking good in sample browser. When I kill the app, in this state, then on restart the same thing happens: We read the same state from disk and restore it lazily. But this time it always works, the tab gets restored and everything's fine. This makes me wonder if there's something going wrong at runtime since restoring the exactly same state after the crash is working as expected.

I was also wondering if this is related to bug 1660546. But since I do not see any surface error, I assume it may be something different.

Comment 1

[Sebastian Kaspari (:sebastian; :pocmo)]

Another maybe interesting thing about case 2: Only the currently active tab turns into this zombie. I'm testing with about:crashcontent. The sessions of all tabs get closed, and we keep the state. The user selects to restore the tabs - we do not actually restore anything immediately and just mark those tabs. The browser still wants to display the currently selected tab and we create a session for it and restore it: White page, can't load anything in it, seems like we do not get any events for it. Now if I switch to another tab, we also create a new session, restore the state... but they just work.

Comment 2

[Sebastian Kaspari (:sebastian; :pocmo)]

Weirdly I only see this happening in Fenix while everything's looking good in sample browser.

I think I found the reason for that. I'm testing with about:crashcontent and:

• In sample browser when entering a URL we show the awesomebar on top of the geckoview (it never gets detached and is there the whole time)
• In Fenix when entering a URL we switch to another fragment for that, so the fragment geckoview is in gets detached.

If I cause a load of about:crashcontent in Fenix while still on the browser screen then the restore will work. So this seems to somehow happen when a session was the active one and is not getting rendered when about:crashcontent happens (or is about to get rendered again). Which also may explain why I only see this happen for the selected tab.

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

[Tracking Requested - why for this release]: We want to make sure we address for 81

Comment 4

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: crashlog.txt

agi asked for a log on riot. in this scenario i have only one tab open, pointing to wikipedia.org. I navigate to about:crashcontent. i then decide to restore, which will cause a new GeckoSession to be created and the last state getting restored. I then end up in the broken tab. The log starts right before I click on the toolbar to enter about:crashcontent and ends in the white page, where i also try to load a URL (theverge.com)

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

According to the log, we don't appear to ever be getting the message to restore, as there is no GeckoView:RestoreState message in the log. The page is white because it has loaded the default about:blank. If there is a navigation to theverge.com we also don't seem to be getting that message either. We do see the JS layer registering to receive the appropriate messages and some other messages (progress for about:blank) going back and forth, so I don't believe the EventDispatcher is broken here. Investigating some more.

Comment 6

[Sebastian Kaspari (:sebastian; :pocmo)]

Agi noticed that we are restoring into the "speculative GeckoSession" (which crashes too) that we open whenever the user goes to the URL bar to edit the URL. So this should be something we can fix on the AC side. I'll take it for now.

Comment 7

[Sebastian Kaspari (:sebastian; :pocmo)]

Fixed on AC side:
https://github.com/mozilla-mobile/android-components/pull/8320

Comment 8

[Julien Cristau [:jcristau]]

Is this also going to get a fix in AC 57.x (for 81), or just 82?

Comment 9

[Sebastian Kaspari (:sebastian; :pocmo)]

So far this is not part of an AC 57 dot release and will ship with the next Fenix release.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

That seems at odds with comment 3.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Per Slack discussion, this isn't being uplifted to 81.