Re: [w3ctag/design-reviews] IFrame Execution Pausing (#369)

@hober I'm not seeing how this can interfer with the user-agent's execution pausing logic. Since it is impossible today to do what the explained in a web compatible way. 

To clarify more are you saying Safari currently pauses iframes that are part of the active tab? I thought it only worked on entire pages that weren't active. Chrome does throttle iframes depending on certain conditions to improve battery life but we refer to that as throttling and not pausing. ie. running an event loop at a slower rate is different than not running any tasks at all.

I understand Apple has some uncertainity towards the page-lifecycle spec. Most I've heard is statements as you've made pausing and resuming aren't free. I'd like to understand what metrics Chrome could collect if we decide to ship this to help you give data to help convince you that we believe this will make the web better for the user.

I'd expect that any policy implemented by a user-agent would take precedence and this proposal is only about providing a more fine grained control over situations that the user agent can't reason about. ie; a user agent doesn't know that this display: none iframe shouldn't really do any work when it isn't displayed. We paused execution on these iframes accidentally in one version a few years ago and we got a large number of reports of the sites we broken. So we know very well that isn't interoperable with the web of today and we need some mechanism to describe these scenarios that the embedder wants.

I believe it will result in significantly more execution pausing than the UA can do. There is signifcant interest in these primitives
1) Experimental code has already been written in AMP (https://github.com/ampproject/amphtml/issues/24110) 
2) There is from ad groups to improve battery life and user experience for pages.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/369#issuecomment-531921023

Received on Monday, 16 September 2019 19:24:05 UTC