Freeze OOPIF frames when freezing is triggered from the renderer |
|||||
Issue descriptionCurrently, when freezing is initiated from the browser, it freezes all frames, including the OOPIF ones. This is done mainly by sending a SetPageFrozen message to all the views that contain frames belonging to the page (i.e. to different processes)(https://cs.chromium.org/chromium/src/content/browser/web_contents/web_contents_impl.cc?rcl=5d15699cc26b8d8c0da0c6a93f07fa2d721ebecc&l=1907) which is in turn distributed to all the local frames. But if the freezing is initiated from the renderer, we only perform the last part. Although, currently, freezing triggered from the renderer is only on Android, where OOPIF is not enabled yet. This need to be addressed before it gets enabled or if renderer freezing is enabled on Desktop.
,
Jul 10
Charlie - when is OOPIF expected to launch on Android? In the future we plan to drive freezing from browser-side entirely and trying to decide if we need an interim fix.
,
Jul 10
There will be an experimental enterprise policy on Android in M68, but it has many known issues, and it may be ok to include this as one of them. We don't have a milestone yet for launching by default, but we're looking at options for later this year.
,
Jul 17
Kentaro, Alexander -- could one of you consider owning this issue? What's the current plan / status of browser side scheduling?
,
Jul 20
In which case do we initiate freezing from the renderer? Could we simply re-route that request through the browser?
,
Jul 20
,
Sep 12
I'd expect freezing logic to independently trigger on each OOPIF, based on the 5min trigger. Needs to be verified.
,
Sep 14
We also want to move the renderer triggering logic out of the renderer, so this becomes a non-issue at that point. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by creis@chromium.org
, Jul 9