Closed Bug 1528327 Opened 6 years ago Closed 6 years ago

Reload page when content process is killed by the system

Categories

(GeckoView Graveyard :: Sandboxing, enhancement, P2)

All
Android
enhancement

Tracking

(Not tracked)

RESOLVED INVALID

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.

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

Flags: needinfo?(agi)

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

Flags: needinfo?(agi)

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.

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.

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.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID

Moving content process management bugs to the new GeckoView::Sandboxing component.

Component: General → Sandboxing
Product: GeckoView → GeckoView Graveyard
You need to log in before you can comment on or make changes to this bug.