Reload page when content process is killed by the system
Categories
(GeckoView Graveyard :: Sandboxing, enhancement, P2)
Tracking
(Not tracked)
People
(Reporter: agi, Unassigned)
Details
Sometimes android will kill our processes, e.g. when the system is out of memory, or the user hasn't interacted with the app for a while. To simulate this behavior, it's possible to just call kill -9
on the process.
When killing the :tab
process with the app in the background, GeckoView will navigate to about:blank
. This is especially bad for CustomTab, that doesn't have a functioning URL bar.
Instead, we should restore the tab state whenever the app is brought to the foreground again, similarly to what happens when the main process is killed.
Comment 1•6 years ago
|
||
Agi, how would this page reloading interact with our crash reporter? We probably don't want to submit crash reports for Android's normal background process culling or system OOMs (but we would want to report Gecko OOMs in content processes).
Reporter | ||
Comment 2•6 years ago
|
||
I don't think the crash reporter is invoked at all in this case, the connection to the child process just dies.
In case of Gecko OOMs an allocation would fail causing an actual crash in the process (and thus a crash report).
Comment 3•6 years ago
•
|
||
we should restore the tab state
My understanding is that right now, GeckoView is built on the principle that it won't save any tab/GeckoSession state at all and it's the embedding app's responsibility to call saveState()
/restoreState()
as required.
Therefore, if we'd want to transparently restore the session state when the tab process dies (as opposed to just telling the embedding app that the session died and could it please restore the state, provided it has any saved state in the first place), we'd have to have some source of up-to-date tab state data in GeckoView itself that could then be used to restore the tab.
In my view, that would basically mean implementing ContentSessionStore (respectively re-using the successor API as far as possible) and the TabStateCache in GeckoView, which as I understand is roughly the direction bug 1463878 is already heading to.
Updated•6 years ago
|
Reporter | ||
Comment 4•6 years ago
|
||
JanH: Yeah my understanding of this area is a little fuzzy. We still want to have the app in charge of responding to the onCrash
event and restore the tab.
Since all GV apps seems to be broken in this case we might not be calling onCrash
here. I'll check that and if that's not the case WONTFIX this bug.
Reporter | ||
Comment 5•6 years ago
|
||
Ok I verified that we correctly call ContentDelegate.onCrash
so GV is behaving correctly, this is a Fenix bug, opened https://github.com/mozilla-mobile/fenix/issues/1577.
Comment 6•3 years ago
|
||
Moving content process management bugs to the new GeckoView::Sandboxing component.
Updated•9 months ago
|
Description
•