Intent to Implement: IFrame execution/freezing feature policy

[Dave Tapuska]

Contact emails dtap...@chromium.org Explainer https://github.com/dtapuska/iframe-freeze Design docs/spec Specification: https://github.com/WICG/page-lifecycle/pull/32 https://github.com/dtapuska/iframe-freeze TAG review https://github.com/w3ctag/design-reviews/issues/369

Summary Add ability to pause execution of an iframe that is not rendered or scrolled out of view. Motivation Suppose a page contains an iframe. It is possible that the embedding document does not wish the iframe to consume CPU or network resources while not actively displayed. Controlling the behavior between two frames requires active communication and co-ordination between the frames. Co-ordination between frames can be difficult because the only way to communicate between frames is via postMessage. So the each side has to coordiante on an API that allows each side to indicate when they should restrict their CPU usage. Risks

Interoperability and Compatibility None Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: Positive AMP team is excited to use this

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes https://wpt.fyi/results/lifecycle?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5684075803181056

[Boris Zbarsky]

On 4/30/19 5:26 PM, Dave Tapuska wrote:
> Co-ordination
> between frames can be difficult because the only way to communicate
> between frames is via postMessage.

Does the proposal envision using this only for different-origin iframes,
or also same-origin (or similar-origin) ones?

> Risks
> Interoperability and Compatibility None

This does not seem accurate to me. This proposal is tightly tied to
document-association of tasks, but (1) pretty much no specs currently do
explicit document-association and (2) implicit document-association of
tasks [1] is not clearly defined in a way that could allow it to be
interoperably implemented.

-Boris

[1] https://html.spec.whatwg.org/multipage/webappapis.html#implied-document

[Dave Tapuska]

Different origin, same origin are all treated the same with respect to this policy. Although the envisionment is that fundamentally this would be used together with https://github.com/whatwg/html/issues/4435

Trying to call directly into a frozen scriptable frame might lead to some undefined behavior. But the policy is explicitly opt in. So it implies there is cooperation in doing so. I suppose a UA may select to apply this policy only to non-directly-scriptable domains (so it would be allowed if 4435 were implemented)

The feature policy builds on freezable task queues that were implemented part of page-lifecycle. Has gecko had problems implementing page-lifecycle because of lack of clarity in the specifications?

dave.

[Boris Zbarsky]

On 5/1/19 9:18 AM, Dave Tapuska wrote:
> The feature policy builds on freezable

> <https://wicg.github.io/page-lifecycle/spec.html#html-task-source-dfn>

> task queues that were implemented part of page-lifecycle. Has gecko had
> problems implementing page-lifecycle because of lack of clarity in the
> specifications?

Gecko has not yet looked into implementing page-lifecycle. But yes, if
we were to go try to implement it, doing so in a way that's
interoperable with Chrome would be completely impossible given the
current state of the specifications.

It's not just "lack of clarity". It's complete nonexistence of an
actual spec; see the first "TODO" bit in the section you linked, which
is hiding a huge amount of work and compat problems.

-Boris