Intent to Implement: PauseFrame API

[Josh Karlin]

Contact emails

TL: jka...@chromium.org

PM: rsc...@chromium.org

Link to explainer.

Link to TAG review.

Summary

Give a high-level description of your change.

Motivation

PauseFrame allows an embedding frame (or the browser in an intervention) to pause and later unpause a child frame. The act of pausing prevents future JavaScript tasks from running, pausing any media elements, prevents rendering (except when necessary for e.g., iframe resizing), and prevents navigation. The frame effectively becomes a static image.

Use cases include:

1. Pausing resource-intensive frames that the user isn't currently paying attention to. For instance, a carousel of frames, where some of the frames are offscreen. The offscreen frames might need to be loaded while offscreen (for performance) but they shouldn’t be allowed to run after loading (for performance).

2. Pausing frames that violate policies (e.g., TransferSizePolicy). This provides a gentle, yet firm response to misbehaving frames. It allows the user to later continue interacting with the frame if they choose to (e.g., unpause if the user clicks on a resume button).

3. As a mechanism for browsers to automatically intervene on resource-intensive frames. Again, the browser might add some UX to allow the user to resume the frame.

Without PauseFrame, there is no way to stop a cross-origin child frame’s script from running short of unloading it.

Risks

Interoperability and Compatibility

No signals from other browsers yet. Web developers have shown enthusiasm.

Ergonomics

Return is async so that pausing can jump to the browser process (to pause child frames) before returning.

Activation

No known activation challenges.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5141555102875648

Requesting approval to ship?

No

[Addy Osmani]

This is exciting! A few questions:

1. Out of curiosity, what was the rationale behind frame.pause() continuing to complete current tasks and resource loads? As an author, I'm keen on the ability to pause event handlers/promise resolution/video loops), but wonder why tasks and requests (which might also be expensive) are similarly not paused as part of this.

2. The explainer states that when a frame has been paused it should be made visually obvious to the end-user that it is not interactive. An overlay with a transparent play button is suggested as one UX affordance. Something unclear to me is if it's the responsibility of the UA to define their paused-state-UX (e.g all paused frames get an unpause button) or if this is an exercise left to the developer.

[ders...@googlemail.com]

For me this is also a welcome step in the right direction!

But have you people ever thought about the possibility to just throttle down iframes (CPU cycle wise)? Because what we really only want is that the main thread stays responsive. And the browser would know best when to slow down, pause, or wind up CPU cycles on an iframe as it knows the load on the main thread as much as it does know when an iframe comes into view or scrolls out of it.

And finally I'd also love to see the ability to mark up scripts as throttled and it would be great if any further DOM elements created by those scripts would themselves also be marked as throttled.

[Josh Karlin]

On Thu, Sep 14, 2017 at 12:41 PM, <ders...@googlemail.com> wrote:

For me this is also a welcome step in the right direction!

But have you people ever thought about the possibility to just throttle down iframes (CPU cycle wise)? Because what we really only want is that the main thread stays responsive. And the browser would know best when to slow down, pause, or wind up CPU cycles on an iframe as it knows the load on the main thread as much as it does know when an iframe comes into view or scrolls out of it.

Definitely. A CPUPolicy API is also in discussion, but I don't have an explainer to point you to yet. Would love to hear more (off-thread) about your use-cases.

[Josh Karlin]

On Thu, Sep 14, 2017 at 12:00 PM, Addy Osmani <ad...@google.com> wrote:

This is exciting! A few questions:

1. Out of curiosity, what was the rationale behind frame.pause() continuing to complete current tasks and resource loads? As an author, I'm keen on the ability to pause event handlers/promise resolution/video loops), but wonder why tasks and requests (which might also be expensive) are similarly not paused as part of this.

Future tasks and resource loads will be paused as well. We let the current ones run as it meets developer expectations that a task won't be interrupted. Further, canceling a request is likely to break a page and could cause trouble for unpause. That said, I hear you. If a frame is downloading a 1GB video in one go it would sure be nice to be able to stop it.

 

2. The explainer states that when a frame has been paused it should be made visually obvious to the end-user that it is not interactive. An overlay with a transparent play button is suggested as one UX affordance. Something unclear to me is if it's the responsibility of the UA to define their paused-state-UX (e.g all paused frames get an unpause button) or if this is an exercise left to the developer.

We'd originally considered an option for the UA to provide UX but decided to leave that to the developer instead. I'll try to clear that up in the explainer.

Thanks!

[Daniel Cheng]

Some questions to help me better understand how this will work:

- What happens to subframes of a paused frame? Are they paused too? I assume it's a transitive thing.

- What if the subframes are cross process frames?

- What happens if a frame interacts with the DOM of a paused frame?

Also, I'm curious if there's a design doc that covers the high-level details of how this would be implemented.

Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaN%2BDy0t-6ijphTmAJm56ACDf3Gwf04--AcEdwpoP_928A%40mail.gmail.com.

[Josh Karlin]

On Thu, Sep 14, 2017 at 1:08 PM, Daniel Cheng <dch...@chromium.org> wrote:

Some questions to help me better understand how this will work:

- What happens to subframes of a paused frame? Are they paused too? I assume it's a transitive thing.

Correct. I'm still working out the details though in regards to which children unpause when unpause is called. (some of those children might have had pause called on them separately).

- What if the subframes are cross process frames?

They'll be paused as well. In Chrome, the browser process will coordinate which frames need to be paused.

 

- What happens if a frame interacts with the DOM of a paused frame?

I'm not sure yet :) Please do share any interesting cases you can think of to consider on the github issues page.

 

Also, I'm curious if there's a design doc that covers the high-level details of how this would be implemented.

There is an internal doc but it doesn't have all that much in the way of detail yet. 

Thanks,

Josh

[robert....@gmail.com]

Is there concern over an XSS when the attacker puts your content in the child?