Intent to Implement and Ship: Freeze task queues in background (desktop) (attempt #2)

[François Doray]

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.  

[Boris Zbarsky]

On 10/4/19 3:30 PM, François Doray wrote:
> Firefox: No public signals

We have repeatedly stated that we perceive significant interop risks
here due to the fact that this is all built on top of freezable task
queues, which are not adequately specified and cannot be implemented
interoperably based on the existing spec text. This is a long-standing
signal about this whole line of work, which is getting persistently
ignored...

There is also significant interop risk in the fact that the opt-out
heuristics are not well-specified and in the existence of an explicit,
non-public, and unspecified opt-out list in Chrome.

-Boris

[Dave Tapuska]

Boris I feel bad if you feel we've been ignoring you because I didn't believe that was the case. Perhaps you want some further clarification in the page lifecycle spec, but let me highlight what we've done.

We did take your comments in previous posts into consideration. When we enumerated all task queues in blink that are specified in the specifications all task queues are freezable. We do have some internal queues that do stuff that aren't web exposed that don't freeze. We removed the text describing some queues and changed is such that all task queues are frozen when the document/frame is frozen.

dave.

--
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 Zbarsky]

On 10/7/19 12:37 PM, Dave Tapuska wrote:
> We did take your comments in previous posts into consideration. When we
> enumerated all task queues in blink that are specified in the
> specifications all task queues are freezable.

That's not the issue. The issue is that freezing is attached to the
document the runnable is associated with, not to the queue per se, and
the spec does not define which documents various runnables are
associated with.

This is also, I think, the second or third time we are having this
_exact_ conversation...

-Boris

[Dave Tapuska]

To close out some uncertainty, I chatted with Boris on IRC and the concern is around the definition in the HTML spec around https://html.spec.whatwg.org/multipage/webappapis.html#implied-document  I'm going to see what it will take to formally add the appropriate document into the construction of each task at each point at which the tasks are queued. 

dave.

[François Doray]

We plan to remove the opt-out list in favor of the origin trial opt-out.

 

-Boris

[Boris Zbarsky]

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

[Rick Byers]

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.

--
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.

[François Doray]

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.

[Jason Chase]

On Tuesday, October 8, 2019 at 1:33:52 PM UTC-4, Francois Pierre Doray wrote:

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?

There isn't a public list. For privacy reasons, we cannot publish the origins that have registered for the opt-out trial. To confirm what Rick said, there is not a list of registered origins in Chrome. The opt-out is only enabled when a page provides a valid trial token, which is issued upon registration. And yes, Google uses the trial registration process to enable the solicitation of feedback and notify developers of updates to the trial.

 

-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.

[Boris Zbarsky]

On 10/7/19 7:30 PM, Rick Byers wrote:
> If desired, it is possible for other browsers to validate the OT tokens
> used by Chrome

That's good to hear; is there documentation on this?

That still doesn't help if the site only presents the token to Chrome,
of course, but I don't know whether sites would tend to do that or not.

-Boris

[Jason Chase]

We only have documentation on the token format:

docs.google.com/document/d/1v5fi0EUV_QHckVHVF2K4P72iNywnrJtNhNZ6i2NPt0M/edit

That doc links to the original design outline (from back in 2015), which has a more context on the intent behind the tokens.

Otherwise, the Chromium source code is the only "documentation" for the validation process (e.g. trial_token_validator.cc?l=48).

I'm happy to discuss in more detail with Mozilla folks. The goal was to enable other browser vendors to have a similar trial program (although we didn't think it likely that other browsers would directly consume Chrome origin trial tokens). I could walk people through Chrome's approach, or we could explore if there's documentation that would be useful and maintainable.

Thanks,

Jason

[Boris Zbarsky]

Jason,

Thank you for the documentation links.

For opt-in origin trials, you're right that directly consuming Chrome's
tokens does not make sense. But for the opt-out ones, where sites are
using the token to opt out of a specced behavior or browser
intervention, and hence the sites would break in other browsers if they
don't consume the token, other browsers would not have much of a
different choice, as far as I can tell.

-Boris

On 10/8/19 5:18 PM, Jason Chase wrote:
>
> We only have documentation on the token format:
> docs.google.com/document/d/1v5fi0EUV_QHckVHVF2K4P72iNywnrJtNhNZ6i2NPt0M/edit

> <http://docs.google.com/document/d/1v5fi0EUV_QHckVHVF2K4P72iNywnrJtNhNZ6i2NPt0M/edit>

> That doc links to the original design outline (from back in 2015), which
> has a more context on the intent behind the tokens.
>
> Otherwise, the Chromium source code is the only "documentation" for the
> validation process (e.g. trial_token_validator.cc?l=48

> <https://cs.chromium.org/chromium/src/third_party/blink/common/origin_trials/trial_token_validator.cc?l=48&rcl=17a184c567d57e9a6b1fcf407c944f9c0e4f6cb7>).

[Jason Chase]

That's an excellent point that we hadn't envisioned opt-out trials back during the initial design.

Recently, we briefly considered if the token format should explicitly identify the type of trial. We didn't pursue it, because it wasn't needed for the Chrome implementation. If other browser vendors are going to consume Chrome tokens, I imagine the straight-forward solution would be to only process the trial names they care about (e.g. something like "PageLifecycleTransitionsOptOut" in this case). However, we could revisit the idea of changing the token format, if it makes implementation easier for other browsers (the format supports versioning).

Thanks,

Jason

[François Doray]

Summary of current state:

• To opt-out a site from freezing, an origin trial should be setup. Any browser can validate the origin trial token (see previous messages from chasej@). Chrome no longer has a list of origins that are opted-out from freezing.
• Our long-term goal is to evolve the spec to allow all background features (e.g. update the title or favicon, play audio...) to be implemented in a freezing-friendly way, and deprecate the opt-out.
• dtapuska@ chatted with bzbarsky@ about the definition in the HTML spec around https://html.spec.whatwg.org/multipage/webappapis.html#implied-document. dtapuska@ will look into the steps required to clarify the notion of implied document.
• Extensions can switch to a tab using the chrome.tabs API. This will unfreeze the tab and allow content scripts to run.

[Alex Russell]

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?

Boris: do you have a preference for how this should be spec'd?

Regards

[Boris Zbarsky]

On 10/24/19 3:50 PM, 'Alex Russell' via blink-dev wrote:
> Boris: do you have a preference for how this should be spec'd?

Ideally, the spec would be explicit about which document any given task
is associated with. Dave has graciously volunteered to try to make that
happen, which I really appreciate.

The specific details of how this should be defined in the spec I don't
have very strong views on; Dave had some suggestions for spec shorthands
for things like queueing node-associated tasks (which would use the node
document of the node in question) which make sense to me.

The one thing I'd really like is that the process of writing this spec
involve checking it against Blink's implementation of
document-association, to flush out any potential discrepancies.

-Boris

[François Doray]

On Thu, Oct 24, 2019 at 3:50 PM 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:

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?

For the moment, Chrome will not freeze tabs sharing a browsing instance with another tab. dtapuska@: Correct me if I'm wrong, but I think this means that we will not freeze a tab when queue/document affinity is open to interpretation, and any adjustment to the spec will not affect how Chrome behaves.

 

--
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.

[Dave Tapuska]

As Francois said Chrome freezes all queues for a unit of related browsing contexts. So while we have taken great care at associating the tasks to the appropriate queues in Chrome even if we did have an issue with the wrong implied document it wouldn't manifest itself as an error. 

I'm hoping to get some time in the coming weeks to start making pull requests on the HTML spec in this regard.

dave.

[Ben Kelly]

Does this feature have an enterprise policy opt-out?  It seems like it a good candidate since its similar to an intervention.  Guidelines for enterprise friendly launches here:

https://www.chromium.org/developers/enterprise-changes 

Note, this is likely orthogonal to the origin trial token.  An enterprise may run into problems with products for which it doesn't own the domain.

The enterprise policy is a small additional amount of work, but mitigates the risk of having to roll back the launch for late reported enterprise issues.  (We've had a few of those lately.)

+Brandon Heenan for visibility. 

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.

[Alex Russell]

Hey all,

Discussed by API OWNERS today. To quickly summarize, wanted to again express support for this feature and a desire to LGTM, but we'd like to see:

• A spec PR to clarify the behavior, per Boris' note
• A commitment to update Chrome's behavior to match spec wherever that discussion lands (which we presume, but would like to confirm)

Thoughts?

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.

[Dave Tapuska]

The first PR is here: https://github.com/whatwg/html/pull/5072/commits/a9b250cce9366cbaa8befb09a246aef5e4525719 obviously once we get it approved and landed it can be a reference for the 50+ references in the spec. One PR isn't going to address Boris's concerns, you probably are looking at a 50 or so PRs (I expect it to take about a month or two)

dave.

[roll...@gmail.com]

I personally believe this to be an affront to all web-developers. I am sorry, but this is sincere opinion. First you took auto play which we used to notify users that something important happend. Now you are actually stopping a web-site from functioning just because the user happens to browse the news while she is waiting for a process to finish. Oh - you say .. what about push notifications? First of all, push is not available under all circumstances. Think about operating systems like Lineage Os. Second: There's no silent push. Every web-site will now need to send push for everything and every update that would have happened silently in the background. I don't want dozens of pushs popping up around me every day. Third: Push remains confined in the service worker and won't reach the website if it is frozen. In other words - each and every update must be triggered new when the website is brought into focus. Forth: Push binds every browser to Firebase. This is a privacy concern. Long polling as well as any form of websocket communications is dead as of now. How are e.g. web-chats supposed to be working now? Good bye to web-rtc or any other form of interactivity. This is incomprehensible. 

And you know: I don't understand the need for it. On battery critical systems, the web-browser is frozen anyway as soon as the phone is idle (+ grace period). 

I urge you to take a step back and ask yourself if you really want to kill the interactive web as we know it.

[Dave Tapuska]

Because Yoav asked me yesterday about the status of this. I don't feel that this intent should block on the PRs to update the HTML spec. Domenic has reviewed the first spec patch and hopefully it should land shortly and then hopefully I'll get some time to work on the roughly 200 other references that end up using Implied Document/Implied Event Loop. But iterating on the HTML spec to address the handy waviness concerns of the current definitions shouldn't hold up shipping.

dave.

[Alex Russell]

Thanks for updating us on the status. I trust y'all to get the follow-up PRs done.

IIRC there was some debate about an OT vs another meta tag to signal the opt-out. Has that been resolved?

Regards

[Daniel Bratell]

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.

[roll...@gmail.com]

The attachment shows a screen shot of a web-based environment used to monitor a complete building. It relies on real-time data delivered via WSS and is able to alert the operator if something requires her attention. It is completely event driven. It is also used, among other things, to monitor senior citizens in their rooms (without cameras, e.g.. blue tooth fall detectors are sending events to a local controller who sends the event to the main controller from which it is broadcasted to all attached screens.  Now - the operator may not have this screen visible at all times. If something comes up, the web-site makes noise and changes it's title so that the operator is alerted. This screen runs on normal computer devices as well as on tablets and other mobile devices.

How are you developers suppose this system should work when the task is frozen in the background? Seriously: What would you suggest we do to keep this environment as reliable and responsive (as in event driven) as it is today?

Thank you for your answer.

Michaela

[lennar...@gmail.com]

/signed

This 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.

Do you think it is sufficient to state that rather significant change just here? Will this news even reach 1% of the developers affected? I seriously doubt it.

This trend is sickening and I was hoping it to be confined to mobile OSes but now it's spilling over to the desktop. The whole thing seems to be ill-conceived and I can only urge you to not do it.

As a side note: Heuristics that are changing behaviour of Chromium are an absolute nightmare for testing. I thought tieing persistent storage allowance to the notification permission was the pinnacle of ridiculous...

Lennart

[lennar...@gmail.com]

Now, I also want to make a constructive suggestion on what could be done instead: Perhaps make background activity more visible to the user (e.g. in form of statistics or perhaps colourising a tab with high background activity). If an origin can opt-out, it's not going to help the user, so let the user decide whether to allow or disallow background activity instead. There could be an API for developers to listen for such an event (and you already have that), so the web page can notify the user if disallowing background activity is an issue for it.

Seamless UX is good and everything but, really, we should stop treating the user like a halfwit. Let the user have a voice again.

Thanks!

Lennart

[François Doray]

Experimenting with freezing on Canary and Dev was a valuable exercise, which allowed us to confirm the potential to reduce memory and CPU usage, and speed up page load time and input delay.

However, at this time, we understand that permanently freezing background pages breaks important Web experiences. We are exploring other solutions to reduce background work, without affecting these important Web experiences. It is important for us that an event-driven chat room, building monitoring app, countdown, 3d printer controller, auto-refreshing doc, etc. keep working, even if they are based on ad-hoc "long polls" or WebSockets instead of the Push API. However, we want to make sure that a page that adjusts the position of a banner of the screen every 100 ms with a Javascript timer (yes, there are pages doing that), will not affect the responsiveness of the foreground tab. Our goal is not to prevent pages to perform work, but to ensure that limited resources are allocated in an optimal way. We still haven't fully figured out how to achieve that.

rollofone@: If I understand correctly, the app you're describing relies on the fact that a Web page can play a sound or update the page title in response to data from a WebSocket? This is definitely something we think should keep working, without any change on the site.

--

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.

[Michaela Merz]

Francois:

As I understand it, background  timers are already slowed down.  As explained, our application receives events via webrtc, modifies icons (e.g. updates the barometric pressure value) and, if necessary, signals the operator with sound and a blinking tab-bar icon. Depending on the selected viewing mode, it may also update a graph. I am glad that you understand that event driven functionality must never be artificially interrupted, blocked, frozen or unloaded. I am glad to assist in any way and to help you to get he browser to reduce artificial and unnecessary loads, while keeping important (e.g. wss, long polling) event driven environments running.

Michaela

[Chris Hamilton]

On Fri, Jan 10, 2020 at 11:41 AM <lennar...@gmail.com> wrote:

/signed

This 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.

Note that we've changed gears here. We no longer intend on shipping long term freezing just cause a tab is backgrounded, as the performance improvements don't justify it, and as many people have pointed out, it causes breakage in a number of ways.

That being said, freezing is still extremely useful as a short term intervention. From the experiments we've already run the biggest benefit to freezing is to reduce loading time for ongoing tab loads, and to improve tab switch times. We are switching gears to making freezing only be about allowing the system to focus CPU/network usage on tabs that are currently very high priority (ongoing load, just been focused). In this world, background tabs will be frozen for very short periods of time (fractions of seconds, with some O(seconds) cap).

 

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.

Complexity from a developer's point of view is quite low. Freezing just means you lose CPU cycle for a short period of time. Database connections, open sockets, open network connections, posted timers, etc, will all survive, and pick up where they left off once the document is unfrozen.

We're exploring alternative throttling mechanisms to limit total impact of lower priority background tabs. These mechanisms allow tabs to keep running just fine. More details to follow soon, but this will be an entirely separate launch from freezing.

[Chris Hamilton]

A handful of Chrome projects have explored this idea several times over the last couple years, but the perceived user value is quite low and the visual clutter unwelcome. We're not treating users as half-wits; the fact of the matter remains that a very very small minority of people would make use of this data. We're committed to supporting power users as well, but to avoid cluttering Chrome (both the codebase and the UI), we prefer to let people develop this kind of functionality themselves using the extension ecosystem.

Cheers,

Chris

On Fri, Jan 10, 2020 at 12:23 PM <lennar...@gmail.com> wrote:

--

[Chris Hamilton]

On Thu, Jan 9, 2020 at 3:45 PM Daniel Bratell <brat...@gmail.com> wrote:

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?

The largest source of information is bug reports. The reason we've decided to use the OT is so that there's some explicit back-channel (an email address) with reasons for why the opt-out has happened. We intend on following-up on these to learn why a site has opted out, and what use case we've broken for them.

Note that a user would never be able to interact with a frozen tab, as a tab would never be frozen if visible. 

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.

[Chris Hamilton]

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.

Cheers,

Chris

--
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.

[lennar...@gmail.com]

First of all, I appreciate that you've come to the conclusion that the original freezing proposal is problematic and that you've already taken action. Let me add a couple of comments (also as a reply to your other post).

The way I see it is that here are legitimate reasons to do background work and even go way beyond the 1% total CPU time budget in a small time frame. There may even be legitimate reasons to do CPU intensive work over a longer period of time. What do I know which use cases people have/will come up with. For example, a messaging app may receive a message that needs to be decrypted. Now, this decryption process itself can be costly. But furthermore, there may be requirements from the protocol to do further work when processing a message, e.g. receive a push, connect to a server, decrypt a message, store it in a database (possibly also in encrypted form), send an encrypted acknowledgement, etc. Even considering just this use case, I'm somewhat certain that there's no heuristic to determine when to throttle that wouldn't break some protocol requirements or impact the user experience. Considering that it's the norm rather than the exception that a messaging app is in the background, the user experience that this proposal is trying to improve is actually going to suffer because of throttling.

I'd like app developers to be responsible instead of being nannied. If there are websites that are mining bitcoins in the background (exaggeration, of course), then the user should know about that. Throttling the background activity is not going to help the user or the developer. If the user knows about it and can decide on what to do about it, then it can also inform the owner of the app of this behaviour. If the app has a legitimate reason to have high background activity, it can let the user know why that is the case. Perhaps this is a utopian dream but I really hope it isn't because I prefer minimalism and an empowered user over hard to test (for the app) and complex heuristics (in the browser engine).

Last but not least I want to emphasize that perhaps it would be a good idea to consider whether platforms such as Electron would emphasize such a change. Because PWAs are awesome in theory but due to browser vendor inconsistencies and constraints like this proposal is suggesting, they are one of the reasons why app developers are shipping full browser engines along with their apps instead. I really wish we didn't have to.

Cheers

Lennart

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[K. York]

> If there are websites that are mining bitcoins in the background (exaggeration, of course)

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 :)

[sha...@peer5.com]

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

[Yoav Weiss]

On Fri, Jan 10, 2020 at 11:47 PM Chris Hamilton <chr...@chromium.org> wrote:

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.

Given those clarifications and the ones on the blink-api-owners thread, this seems like a safe enough change.

LGTM1

[Ben Kelly]

Wait, is this particular intent to ship still active?  My impression was that there was design and implementation work to do on the micro-freezing approaches.  I guess I was expecting a new intent to ship once the new approaches were fully fleshed out and defined.

--

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.

[Michaela Merz]

That's what I thought as well. The idea of freezing, unloading or slowing backgrounded tasks is, in my opinion, deeply consequential and requires much more thought and discussion.

Michaela 

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Daniel Bratell]

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.

[François Doray]

tl;dr We will not continue to work on this specific intent to ship.

Many popular sites do work in the background without providing clear user value. It is still our objective to reduce that work. However, we believe that completely stopping work in background tabs is not the right solution. The performance gains do not outweigh the breakages that we have observed on some sites that provide useful functionality while backgrounded. We will continue our exploration of the problem space and come back to a separate email thread on blink-dev@ once we have other proposals.

Thanks!

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.

[Michaela Merz]

Thank you @François . 

I think this is the best way forward. It may make sense to give us updates from time to time as I am sure many of us will have meaningful ways to contribute.

Michaela

[lennar...@gmail.com]

I like the scheduler.postTask approach and I think that is the more developer and user-friendly way to progress on this issue: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/31qZ-bMToM8/bLhpSdXhEgAJ

Perhaps you can combine your efforts.

Cheers

Lennart

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.

[Shachar Zohar]

I like the scheduler.postTask approach

I agree, maybe the direction should be instead of the browser engine to decide how to throttle all javascript background tasks in general, that should be left to developers.

For example, all scripts by default should not work or throttled in the background, unless they specifically opt-in for "don't throttle when in background"

Or a top page policy (like CSP tags) for allowing specific scripts to do background work.

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.

--

Shachar Zohar

CTO, Peer5

Book a meeting with Peer5

+1-650-4853542 | sha...@peer5.com | skype: shachar.zohar1