Contact emails
fdo...@chromium.org, dtap...@chromium.org
Explainer
Enable page freezing on desktop. The feature has already shipped on mobile.
Design doc/Spec
Specification: https://wicg.github.io/page-lifecycle/spec.html
Original TAG review: https://github.com/w3ctag/design-reviews/issues/283
List of task queues that can be frozen: https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/public/platform/TaskTypes.md
Design doc of the mobile version (already shipped)
Summary
All freezable task queues of a page that has been backgrounded for 5 minutes will be frozen simultaneously, if the page is “freezable”.
A page is “freezable” if it hasn’t opted-out of freezing via origin trial and if it hasn’t been opted-out by heuristics. See Page Freezing Opt-In and Opt-Out.
Note: This is an intent to freeze task queues in background pages. Freezing task queues to support BFCache will be addressed by a separate intent.
Motivation
This feature has already shipped on mobile. Shipping it on desktop makes the platform consistent.
This feature provides CPU, battery and memory usage improvements (per experimentation on Canary/Dev channels).
Risks
Interoperability and Compatibility
A page that communicates with the user when backgrounded (e.g. by updating its title or playing a sound) might not work correctly if its task queues are frozen. Also, page that holds a lock (e.g. Web Lock, IndexedDB transaction) can cause infinite wait times in other pages that try to acquire the same lock if its task queues are frozen. This is mitigated by providing an explicit opt-out and automatic opt-outs via heuristics. See Page Freezing Opt-In and Opt-Out.
PostMessage may not be delivered right away anymore. We considered adding a lifecycleState property to service worker Client, to let the service worker know when it has a frozen client. However, there was indecision on the API at TPAC, so we decided to hold onto this API for now.
Clients frozen by this feature will appear in Clients.matchAll(), it will be possible to focus them with Client.focus(), and they will be able to block service worker activation.
We have experimented with this feature for many weeks on the Chrome Canary/Dev channels.
Edge: No public signals
Firefox: No public signals
Safari: No public signals
Web / Framework developers: No signals
Debuggability
Freezing can be manually triggered and tested via chrome://discards.
A JS callback is emitted when the intervention is triggered.
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
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5193677469122560
Requesting approval to ship?
Yes
Previous version
An Intent to Implement and Ship this feature was previously sent and retracted https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Ik4vvlOg0jc. This new attempt addresses the feedback received in the first attempt.--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bf8be33b-fb08-3ef6-ef2f-ca1288f60c2f%40mit.edu.
-Boris
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/935b4885-7077-5e1b-490b-55bc1b36b1b0%40mit.edu.
If desired, it is possible for other browsers to validate the OT tokens used by Chrome (one of the original design requirements of OriginTrials). AFAIK Chrome doesn't use a "list" for any reason other than just soliciting feedback on the trial. +Jason who is the expert.
On Mon, Oct 7, 2019 at 7:30 PM Rick Byers <rby...@chromium.org> wrote:If desired, it is possible for other browsers to validate the OT tokens used by Chrome (one of the original design requirements of OriginTrials). AFAIK Chrome doesn't use a "list" for any reason other than just soliciting feedback on the trial. +Jason who is the expert.For completeness, there is code in Chrome to opt-out/in sites from freezing using a "list". However, we want the list to be empty when we ship page freezing to Chrome stable. The correct mechanism to opt-out of page freezing will be the origin trial opt-out.On Mon, Oct 7, 2019, 6:46 PM Boris Zbarsky <bzba...@mit.edu> wrote:On 10/7/19 5:05 PM, François Doray wrote:
> We plan to remove the opt-out list in favor of the origin trial opt-out.
Yes, the list of sites that have registered for the opt-out origin trial
is the "non-public and unspecified" list I referred to... At least I
have not found a way to access this list so far. Is there one that I
missed?
-Boris
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Hey all,The OWNERS met today and we're grateful to hear about the removal of a specific site list in favour of OTs. Thanks for making this happen.We're inclined to LGTM this, there's an open question about the potential impact of the spec going one way or the other with regards to Boris' queue/document affinity concern up-thread. If we ship this now, and change or spec that affinity in a different way, what will the visible impact of bringing our implementation into alignment be?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a38a075b-e718-4ad5-8f09-e32891377330%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZWoOtR6YmSyh%2BLVTJA0SzmfeuUSt-7%3DYsvcXDcdiWpgEg%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a38a075b-e718-4ad5-8f09-e32891377330%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
So the idea is to give an opt-out for some time. I have a couple of questions here that might affect exactly how this is deployed:
The opt out will be in the original trial system which is only
for Chrome. How can other embedders avoid breaking sites that have
opted out in Chrome? Is this implemented in code that is shared
between embedders? Anyone from Opera or Microsoft that can
comment?
What signals can be used to discover if this affects more sites than expected? Bug reports? Number of sites signing up to the opt-out? Some kind of user behaviour when interacting with a frozen tab?
/Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4e6f7292-7412-4025-8964-bcb1a8d6c5ec%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/897bde77-7e06-4725-83a1-4d6574336d6a%40chromium.org.
/signedThis is yet another step towards dictating developers and users which use cases are legitimate and which aren't, following the trend on smartphones where in the name of battery life, Google, Apple and a bunch of vendors selling Android phones are doing their best to turn them into dumbphones. You are killing use cases you didn't even know exist and stifle those that haven't even been invented yet.
What about the complexity added by all of this? What about the exceptions? Are they "complete" or is it even possible to have a full overview of all the things that can be affected? In all honesty, claiming so seems like blind arrogance to me. Maintaining these exceptions will be a nightmare for Chromium developers, web page/app developers and end users. Will open WebSockets just be killed? Will open WebRTC Data Channels just die because there's no audio/video involved to trigger an exception? These are just two things that just occurred to me.
--
So the idea is to give an opt-out for some time. I have a couple of questions here that might affect exactly how this is deployed:
The opt out will be in the original trial system which is only for Chrome. How can other embedders avoid breaking sites that have opted out in Chrome? Is this implemented in code that is shared between embedders? Anyone from Opera or Microsoft that can comment?
What signals can be used to discover if this affects more sites than expected? Bug reports? Number of sites signing up to the opt-out? Some kind of user behaviour when interacting with a frozen tab?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/563ade26-d812-cb09-81cd-21e4551b8589%40gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7edca3b4-ed5f-4ce0-a16e-ca3d3e0e7362%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
Not an exaggeration; sites have been caught putting crypto mining scripts on the pages, as well as hackers putting those scripts on other people's web servers.
Of course, fixing that isn't the goal of this; I am led to understand the goal is to fix the "Chrome gobbles RAM" complaints via freezing tabs and maybe in the future writing them to disk...? Future stuff :)
I'd like to reinforce Lennart's argument.
As browser developers, you know that use-cases for web apps can go in unexpected directions. Take for example an app like Webtorrent or numerous apps that are built on top of it - throttling background work can significantly throttle the amount a user can download or upload. Furthermore, since torrent like applications use tit-for-tat and gossip mechanisms, the fact that a user is currently in the background, throttled, and not able to upload very much will hurt him when he goes into the foreground and tries to download (fast) from other end-users. Keep in mind that the application already provides a mechanism for the end user to throttle his up / down speed if he'd like to do so.
Another example is Peer5 (where I am CTO) - an enterprise P2P (WebRTC) CDN that helps alleviate ISP link congestion during large video streaming events. There are scenarios where the Javascript P2P engine and the video playback engine need to run in different contexts. One can be in the background while the other is in the foreground. But it is vital for the viewing experience that the P2P engine can run in the background and deliver the video segments requested by the foreground player process over webrtc-datachannels without throttling or interruptions.
Thanks,
Shachar
In the current implementation, background timers aren't directly slowed down, but rather renderers are given a wakeup budget (no more than once per second), and a total CPU budget (1% CPU). This can result in timer coalescing (distinct timers fire back to back at lower resolution than usual) and arbitrary delays (post too many timers that do too much work, and you can exhaust your CPU budget and wait arbitrarily long before doing all the work you want to).(Note, right now the budget is actually spread across all backgrounded frames hosted in a single renderer. Which means one bad frame can impact others. We're also working on reworking this logic so that each frame gets its own budget, and that all frames in an entire frame tree share a single per-tab budget. This won't materially impact throttling, but it will make it fairer.)We're exploring the idea of making a distinction between internal interrupts (timers and the like) and external interrupts (network data arriving, or a post-message from another frame). The idea being that we'd rate limit internal interrupts at a stricter rate than external interrupts. Furthermore, if an external interrupt results in user visible action (tab title changed, favicon changed, notification was fired), then we could imagine refreshing/boosting the external interrupt budget. Rough ideas for now, but we appreciate the fact that freezing as currently stated breaks a whole suite of event driven applications.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhCKY5r-o6aSpwfKdUEqPv4i9rLVVO4Q0n13dTf97rw%2Bw%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
It's my understanding that this request has now morphed enough,
thanks to your and others' contributions, that it's not much like
the initial request at all. I can see how this change over time
can become a source of confusion and it might be best to file a
new request covering the current idea.
/Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/83e82998-099c-4e5f-be3b-6216944131f2%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0bfb2c8b-2f28-cfee-2240-83cd3a9fb921%40gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/83e82998-099c-4e5f-be3b-6216944131f2%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0bfb2c8b-2f28-cfee-2240-83cd3a9fb921%40gmail.com.
I like the scheduler.postTask approach
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/sotCDcI-E7Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0906f49b-320e-4d32-9b96-606ac3bd23f6%40chromium.org.