[webapp-container] apps are not handled by lifecycle management properly

[Oliver Grawert]

in image 137, if you open a gazillion of apps and have webapps among them, the webapp screenshots never turn blurry when the OOM score is reached on high memory pressure ... once you switch to such a webapp, the whole content window turns white (sometimes the app header stays around, sometimes the whole app window is white).

seemingly the renderer is lifecycle managed and gets properly OOM killed on high memory pressure , but the frontend of the webapp does not.

[Michał Sawicz (saviq)]

Let's stop calling it "lifecycle managed" as that suggests our app management actually has anything to do with it. It's all about the out-of-memory killer and how it behaves. It will just kill one process that it sees fit to kill (in this case, the renderer), so the *app*, being the webapp container, lives on. So there's no screenshot, per se, it's all the app still working (but SIGSTOP'ed, suspended). Once you focus it, it realizes it lost the renderer and the web canvas goes blank (totally blank if webapp has no header, header still around if it was there in the first place).

There's two potential solutions here:
a) get OOM to kill the whole pgroup
b) make the webapp container recover by restarting its renderer

a) would be more in line with our overall lifecycle management
b) could be quicker, as we only need to start the renderer, not the whole app, but the shell won't have control over how the recovery looks

[Ted Gould (ted)]

For "emergency" mode we're talking about making it so that we don't set the OOM value on the oxide processes, then we can research how to get the OOM killer to kill the whole cgroup.

[Alexandre Abreu (abreu-alexandre)]

To be noted:

- killing the whole cgroup would be a valid solution for webapps per-se since atm they are mostly single webview entities but most likely not for the webbrowser-app which basically is the host for multiple webviews. Killing the whole webview bits might be trickier and not desirable from the perspective of per-tab state preservation ...

- there are some tasks in the pipe that would deal with those issues (discussed during the Washington sprint):
     - making webapps a single process (which would simplify the klling process),
     - having an api for the webview to be informed that the renderer process has been killed (ongoing work and also needed to properly solve other issues, like proper handling of window.close()),
     - clever handling of background tabs strategies for the oom killer ...

Those above are being prioritized and/or worked on atm,

[Pat McGowan (pat-mcgowan)]

tagged for review and tracking

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.