Intent to Ship: Freezing on Energy Saver

[Chromestatus]

Contact emails

fdo...@chromium.org, shas...@chromium.org

Explainer

None

Specification

https://wicg.github.io/page-lifecycle

Design docs

https://docs.google.com/document/d/1uTJifh_erMX4_CTKgKljlj9O4SAmGam5W61FBHeasGI/edit?usp=sharing

Summary

When Energy Saver is active, Chrome will freeze a "browsing context group" that has been hidden and silent for >5 minutes if any subgroup of same-origin frames within it exceeds a CPU usage threshold, unless it: - Provides audio- or video-conferencing functionality (detected via microphone, camera or screen/window/tab capture or an RTCPeerConnection with an 'open' RTCDataChannel or a 'live' MediaStreamTrack). - Controls an external device (detected via usage of Web USB, Web Bluetooth, Web HID or Web Serial). - Holds a Web Lock or an IndexedDB connection that blocks a version update or a transaction on a different connection. Freezing consists of pausing execution. It is formally defined in the Page Lifecycle API. The CPU usage threshold will be calibrated to freeze approximately 10% of background tabs when Energy Saver is active.

Blink component

Blink>Scheduling

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interoperability: This feature does not expose new capabilities to the Web, so it has low chances of creating situations in which the same HTML/CSS/Js/... behaves differently in different browsers. That being said, we invite other browsers vendors that already shipped "tab freezing" to share and discuss their opt-out rules, which will help offer consistent behavior for web developers across browsers, avoiding situations where a site's background functionality works correctly in some browsers but not others. Compatibility: This feature may affect existing sites with background functionality. However, breaking some functionality to extend battery life is in line with user expectations when "Energy Saver" is active. We're interested in Web developer feedback to adjust our opt-outs and minimize avoidable breakages. "Energy Saver" can be disabled via the the "BatterySaverModeAvailability" enterprise policy.

Gecko: Under consideration (https://github.com/mozilla/standards-positions/issues/87)

WebKit: No signal

Web developers: No signals In the past, Web developers expressed concerns about freezing, because it made it difficult to implement background functionality that users care about in a reliable way (e.g. notification for calendar event). By freezing only pages that use a lot of CPU and only when Energy Saver is active, breakages that were reported in the past are mitigated. Additionally, we will listen to Web developers feedback on multiple channels (crbug, blink-dev, stack overflow, twitter, github) and make adjustments to heuristics if we find that background functionality that users care about is broken. Users may deactivate Energy Saver or manually opt-out sites at chrome://settings/performance

Other signals: Chrome on Android freezes background tabs after 5 minutes (https://groups.google.com/a/chromium.org/g/blink-dev/c/NKtuFxLsKgo/m/brL3bfS5CAAJ). Chrome on desktop and Android freezes pages before putting them in the BFCache. Chrome on desktop freezes tabs in collapsed tab groups. Edge freezes background tabs after a configurable timeout (https://www.microsoft.com/en-us/edge/features/sleeping-tabs-at-work?form=MT00D8).

Ergonomics

No Ergonomics Risks identified.

Activation

No action is required to support browsers that don't freeze pages.

Security

A frame can observe when it is frozen, either directly (via the “freeze” event) or indirectly (timer runs later than expected, server doesn’t receive a ping…). When the decision to freeze a frame depends on observations made on other cross-origin frames (crossing CPU usage threshold, using Web API that opt-outs from freezing) there is a risk of leaking information across origins. Multiple solutions were considered to balance security and ergonomy requirements. We finally landed on "freezing a browsing context group based on independent observations made on groups of same-origin/same-page frames in that browsing context group". Pros & cons + All frames on a page are in the same “frozen” state (does not break Web devs assumptions). + All frames that can synchronously script each other are in the same “frozen” state (does not break Web devs assumptions). + Not aggregating CPU usage across origins minimizes leaks, because an attacker can’t vary its own CPU usage to precisely measure the CPU usage of another origin. - Leaks Web API usage across cross-origin frames (a frame can learn that a cross-origin frame in the "browsing context group" uses or doesn't use one of the APIs that prevents freezing depending on whether it itself gets frozen).

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

This is a desktop-only feature which does not affect Webview.

Debuggability

The frozen state of a tab is displayed in the "Lifecycle state" column of chrome://discards. Whether a page can be frozen and why (e.g. usage of WebRTC) is displayed in the "Is freezable" column of chrome://discards. The #freezing-on-energy-saver and #freezing-on-energy-saver-testing features at about:flags can be used to test this intervention. It is also possible to manually freeze a tab via chrome://discards to verify how it reacts.

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

Yes

Chrome for Android already freezes pages in the background (not tied to Energy Saver). This proposal brings freezing to desktop.

Is this feature fully tested by web-platform-tests?

No

Flag name on about://flags

freezing-on-energy-saver

Finch feature name

FreezingOnBatterySaver

Requires code in //chrome?

False

Tracking bug

https://crbug.com/325954772

Launch bug

https://launch.corp.google.com/launch/4282880

Measurement

This feature doesn't introduce new APIs that web pages need to adopt.

Availability expectation

This feature doesn't introduce new APIs that other browsers need to make available. It expands the sets of conditions under which Chrome may freeze tabs (previously, only tabs in collapsed tab groups could be frozen).

Adoption expectation

This feature doesn't introduce new APIs that web pages need to adopt. Web pages may listen to the freeze/resume events to react to freezing, but it's not an issue if a web page doesn't. These events are already dispatched when a tab in a collapsed tab group is frozen.

Adoption plan

In collaboration with DevRel, we will publish an article covering the conditions under which freezing is triggered and possible remediations for broken background use cases.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Estimated milestones

Shipping on desktop	133
DevTrial on desktop	132

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

This feature does not modify the spec. It changes the conditions under which tabs are frozen in Chrome. Those conditions are expected to evolve over time.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5158599457767424?gate=5076873410772992

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG9b2qVcRLRWXUz61AkRWi%2BkaOJwgUK8bNCRBG6LOpqgOd%2BvSw%40mail.gmail.com
Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/Xu1C7WhoGm4/m/_9U_kLHDAwAJ

This intent message was generated by Chrome Platform Status.

[Rick Byers]

I evaluated this intent relative to our compat principles and overall think you've done an excellent job mitigating the compat risks. In particular the user controls, developer-influencable heuristics and enterprise opt-out seem likely to be significant mitigations. I'm also confident that you will be proactive in monitoring for issues and being responsive to feedback. 

Heuristics like the energy saver and CPU threshold seem great to me on balance, but I'm also nervous that they will make troubleshooting rare but severe issues harder (especially since these signals can't really be monitored via web page telemetry). We've learned from one recent incident that sometimes the rarest incidents can be extremely bad - eg. causing a serious business disruption for one single organization but not more widely (making support for that organization much harder). In such cases, discoverability and understandability of the issue (including by skilled IT support personnel) is key to avoiding extended outages. With that in mind, I have a couple questions:

Does Chrome have any visual indication that a tab has been frozen? How discoverable is it for users that they can add a site to an exclusion list?

Is the plan for Chrome 133 to be fully at 100%, with 132 still well below that? I'm just wondering to what extent someone looking into website logs for an issue will be able to detect a clear correlation with Chrome 133 (increasing the chance that they reach out to us or find this mentioned in the chrome 133 blog post)?

Will the blog post you mentioned be published prior to 133 beta (Jan 15)? I see it's mentioned in Chrome 131 enterprise release notes already, thank you!

Thanks,

   Rick

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67462b62.2b0a0220.19a388.0546.GAE%40google.com.

[Francois Pierre Doray]

Hi Rick,

Thanks for raising your concerns regarding troubleshooting issues caused by Tab Freezing on Energy Saver.

> Does Chrome have any visual indication that a tab has been frozen?

There is no indication that a tab is frozen. However, the feature only operates when Energy Saver is active, signaled by a leaf icon next to the omnibox. When Energy Saver is first activated or when the leaf icon is clicked, a bubble indicates that "Background activity and some visual effects may be limited".

We avoided a frozen tab indicator because in the long term (2-3 years), we plan to freeze most background tabs, to ensure that they don't steal resources from the foreground tab. At that point, there will be a visual indication for tabs that are not frozen (e.g. playing audio = speaker icon, using the progress notification API to do arbitrary work = UI TBD). 

> How discoverable is it for users that they can add a site to an exclusion list?

Users can add sites to the exclusion list via the "Performance" tab in Chrome settings (direct link: chrome://settings/performance), under "Always keep these sites active." This is also mentioned in the help article (will be updated for this launch).

While discoverability is limited, most users won't need this feature. Typical mail/chat/calendar/phone/drive/music streaming/videoconferencing/... apps will either not exceed the CPU threshold for freezing or be opted out via API usage. Sites requiring high background CPU usage under Energy Saver (outside of audio/video calls, device control...) can direct users to the Chrome settings page or recommend using this policy to enterprise admins (policy doc will be updated for this launch).

We think that requiring some effort to allow high background CPU usage under Energy Saver is reasonable, as it can significantly impact battery life and contradicts Energy Saver's purpose (note: Energy Saver is only available on battery power, activates when battery level is below 20% by default).

> Is the plan for Chrome 133 to be fully at 100%, with 132 still well below that?

The plan is to experiment on 1% of stable users in Chrome 133 and then ramp up gradually as we gain confidence that the feature is well tuned. The feature is already under experimentation in Canary/Dev.  We intend to expand Tab Freezing beyond Energy Saver in the future, taking into account lessons learned from this limited scope launch, but that will be handled under new Intents.

> Will the blog post you mentioned be published prior to 133 beta (Jan 15)?

That's the goal, though DevRel hasn't confirmed a date. I'll check in with them.

Have a nice day,

François

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

tl;dr: Just one remaining question about providing a developer opt-out (like a deprecation trial).

On Fri, Nov 29, 2024 at 12:25 PM Francois Pierre Doray <fdo...@chromium.org> wrote:

Hi Rick,

Thanks for raising your concerns regarding troubleshooting issues caused by Tab Freezing on Energy Saver.

> Does Chrome have any visual indication that a tab has been frozen?
There is no indication that a tab is frozen. However, the feature only operates when Energy Saver is active, signaled by a leaf icon next to the omnibox. When Energy Saver is first activated or when the leaf icon is clicked, a bubble indicates that "Background activity and some visual effects may be limited".

Ah cool, I had never noticed that before myself. I see there's also a prominent "turn off now" button:

 

That seems like a significant mitigation to me. If someone is having trouble with some site it seems like there's a decent chance that they (or their IT support people) would notice this indicator, click it, then click "turn off now" and confirm that fixes the issue. From there I'd imagine troubleshooting would be pretty easy (google searches for "chrome energy saver" would point to the per-site opt-out etc.)

We avoided a frozen tab indicator because in the long term (2-3 years), we plan to freeze most background tabs, to ensure that they don't steal resources from the foreground tab. At that point, there will be a visual indication for tabs that are not frozen (e.g. playing audio = speaker icon, using the progress notification API to do arbitrary work = UI TBD). 

I love that long-term plan, thanks! Personally I'd love to have a mode where pages get to run in the background only if they show such an icon or in response to me granting their origin that permission. That's not behind a flag or anything yet, right?

> How discoverable is it for users that they can add a site to an exclusion list?

Users can add sites to the exclusion list via the "Performance" tab in Chrome settings (direct link: chrome://settings/performance), under "Always keep these sites active." This is also mentioned in the help article (will be updated for this launch).

Yeah I saw that, and I like that the UI contains a "current sites" list rather than requiring copying URLs. But that alone certainly is not discoverable for a user who simply has a broken web page and doesn't know why. But given that disabling energy saver is very discoverable, that's good enough for me as long as this is coupled just to energy saver. I guess you won't really have a way to measure how much site compat issues lead users to disable energy saver, eh? I imagine most users disabling it will do so for the performance / visual quality concerns, not site compat reasons.

While discoverability is limited, most users won't need this feature. Typical mail/chat/calendar/phone/drive/music streaming/videoconferencing/... apps will either not exceed the CPU threshold for freezing or be opted out via API usage. Sites requiring high background CPU usage under Energy Saver (outside of audio/video calls, device control...) can direct users to the Chrome settings page or recommend using this policy to enterprise admins (policy doc will be updated for this launch).

Yes I'm definitely convinced that "most" (probably even >99.99%) of users won't have a problem - your design is great for that, thank you! But what I've learned from my incident post-mortem responsibilities is that it's the ~0.0001% of users that we have to really focus on to reduce the risk of most OMGs. Ask Robert about why I'm afraid of his wrath around this next time you see him in the office :-).

Realistically I'd expect most such sites to just hack in some API usage that tickles your heuristic (like take an IndexedDB lock just for the purposes of being kept alive). That 's going to be much more effective for them than trying to direct users to take some manual steps, right? That seems unfortunate to me, as it will make your life harder in driving down the exceptions. Experience with this sort of thing is a big part of the motivation behind our guidance for providing explicit developer opt-outs for breaking changes (especially interventions like this). Sure, there is some risk of an explicit opt-out being abused but that risk isn't necessarily any greater than abuse of your heuristic, and at least you can more easily measure and track it and update behavior as necessary for any "arms race" with abusive sites. Have you considered offering developers a deprecation trial to reduce the risk of them abusing your heuristics and get you contact info for the developers who feel they must opt-out?

We think that requiring some effort to allow high background CPU usage under Energy Saver is reasonable, as it can significantly impact battery life and contradicts Energy Saver's purpose (note: Energy Saver is only available on battery power, activates when battery level is below 20% by default).

I suspect that most impacted users would simply disable energy saver completely rather than make the extra effort to discover and use the site-specific opt-out. But that's fine - both settings aren't hard to find, and if you see a lot of users disabling energy saver then you can do some research to see if better per-site controls might help reduce that (though we might be stuck for the users who have already opted out completely). 

> Is the plan for Chrome 133 to be fully at 100%, with 132 still well below that?

The plan is to experiment on 1% of stable users in Chrome 133 and then ramp up gradually as we gain confidence that the feature is well tuned. The feature is already under experimentation in Canary/Dev.  We intend to expand Tab Freezing beyond Energy Saver in the future, taking into account lessons learned from this limited scope launch, but that will be handled under new Intents.

Ok, we've come to appreciate that that pattern increases the risk somewhat because it makes it even harder for IT admins and support personnel to reproduce and action site compat issues their users are complaining about. I don't think we've yet come up with some well-informed guidance for mitigating this risk, so I won't ask for something different (eg. could keep to <10% in 133 and then go 100% in 134). But it's something to keep an eye out for in customer reports and perhaps inform our future guidance, so please let me know (here or privately) if it ends up showing up as an issue in customer reports or not.

> Will the blog post you mentioned be published prior to 133 beta (Jan 15)?

That's the goal, though DevRel hasn't confirmed a date. I'll check in with them.

Ok, thanks. If the blog post gets delayed, please hold off on extending the experiment to stable until the blog post is live.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[François Doray]

On Friday, November 29, 2024 at 3:13:39 PM UTC-5 Rick Byers wrote:

tl;dr: Just one remaining question about providing a developer opt-out (like a deprecation trial).

On Fri, Nov 29, 2024 at 12:25 PM Francois Pierre Doray <fdo...@chromium.org> wrote:

Hi Rick,

Thanks for raising your concerns regarding troubleshooting issues caused by Tab Freezing on Energy Saver.

> Does Chrome have any visual indication that a tab has been frozen?
There is no indication that a tab is frozen. However, the feature only operates when Energy Saver is active, signaled by a leaf icon next to the omnibox. When Energy Saver is first activated or when the leaf icon is clicked, a bubble indicates that "Background activity and some visual effects may be limited".

Ah cool, I had never noticed that before myself. I see there's also a prominent "turn off now" button:

 

That seems like a significant mitigation to me. If someone is having trouble with some site it seems like there's a decent chance that they (or their IT support people) would notice this indicator, click it, then click "turn off now" and confirm that fixes the issue. From there I'd imagine troubleshooting would be pretty easy (google searches for "chrome energy saver" would point to the per-site opt-out etc.)

We avoided a frozen tab indicator because in the long term (2-3 years), we plan to freeze most background tabs, to ensure that they don't steal resources from the foreground tab. At that point, there will be a visual indication for tabs that are not frozen (e.g. playing audio = speaker icon, using the progress notification API to do arbitrary work = UI TBD). 

I love that long-term plan, thanks! Personally I'd love to have a mode where pages get to run in the background only if they show such an icon or in response to me granting their origin that permission. That's not behind a flag or anything yet, right?

"Pages get to run in the background only if [they show some UI]" : In 2-3 years, we'd like this to be the default behavior, due to the expected foreground tab speed up and battery savings. It's not yet behind a flag.

> How discoverable is it for users that they can add a site to an exclusion list?

Users can add sites to the exclusion list via the "Performance" tab in Chrome settings (direct link: chrome://settings/performance), under "Always keep these sites active." This is also mentioned in the help article (will be updated for this launch).

Yeah I saw that, and I like that the UI contains a "current sites" list rather than requiring copying URLs. But that alone certainly is not discoverable for a user who simply has a broken web page and doesn't know why. But given that disabling energy saver is very discoverable, that's good enough for me as long as this is coupled just to energy saver. I guess you won't really have a way to measure how much site compat issues lead users to disable energy saver, eh? I imagine most users disabling it will do so for the performance / visual quality concerns, not site compat reasons.

We could run a HaTS survey to understand what leads users to add sites to the exclusion list. Let me know what you think and I can prioritize this.

 

While discoverability is limited, most users won't need this feature. Typical mail/chat/calendar/phone/drive/music streaming/videoconferencing/... apps will either not exceed the CPU threshold for freezing or be opted out via API usage. Sites requiring high background CPU usage under Energy Saver (outside of audio/video calls, device control...) can direct users to the Chrome settings page or recommend using this policy to enterprise admins (policy doc will be updated for this launch).

Yes I'm definitely convinced that "most" (probably even >99.99%) of users won't have a problem - your design is great for that, thank you! But what I've learned from my incident post-mortem responsibilities is that it's the ~0.0001% of users that we have to really focus on to reduce the risk of most OMGs. Ask Robert about why I'm afraid of his wrath around this next time you see him in the office :-).

Realistically I'd expect most such sites to just hack in some API usage that tickles your heuristic (like take an IndexedDB lock just for the purposes of being kept alive). That 's going to be much more effective for them than trying to direct users to take some manual steps, right? That seems unfortunate to me, as it will make your life harder in driving down the exceptions. Experience with this sort of thing is a big part of the motivation behind our guidance for providing explicit developer opt-outs for breaking changes (especially interventions like this). Sure, there is some risk of an explicit opt-out being abused but that risk isn't necessarily any greater than abuse of your heuristic, and at least you can more easily measure and track it and update behavior as necessary for any "arms race" with abusive sites. Have you considered offering developers a deprecation trial to reduce the risk of them abusing your heuristics and get you contact info for the developers who feel they must opt-out?

I hadn't considered a deprecation trial, but I think it's a good idea to reduce the risk of Web developers abusing our heuristics. In terms of process, should I create a "Feature removal" entry at chromestatus.com or can we handle this as part of this intent?

 

We think that requiring some effort to allow high background CPU usage under Energy Saver is reasonable, as it can significantly impact battery life and contradicts Energy Saver's purpose (note: Energy Saver is only available on battery power, activates when battery level is below 20% by default).

I suspect that most impacted users would simply disable energy saver completely rather than make the extra effort to discover and use the site-specific opt-out. But that's fine - both settings aren't hard to find, and if you see a lot of users disabling energy saver then you can do some research to see if better per-site controls might help reduce that (though we might be stuck for the users who have already opted out completely). 

"though we might be stuck for the users who have already opted out completely": If we observe any significant difference in the number of Energy Saver activations between the Control/Enabled groups, or if we observe an upward trend of users without Energy Saver after the launch, we'll investigate why and make adjustments.

 

> Is the plan for Chrome 133 to be fully at 100%, with 132 still well below that?

The plan is to experiment on 1% of stable users in Chrome 133 and then ramp up gradually as we gain confidence that the feature is well tuned. The feature is already under experimentation in Canary/Dev.  We intend to expand Tab Freezing beyond Energy Saver in the future, taking into account lessons learned from this limited scope launch, but that will be handled under new Intents.

Ok, we've come to appreciate that that pattern increases the risk somewhat because it makes it even harder for IT admins and support personnel to reproduce and action site compat issues their users are complaining about. I don't think we've yet come up with some well-informed guidance for mitigating this risk, so I won't ask for something different (eg. could keep to <10% in 133 and then go 100% in 134). But it's something to keep an eye out for in customer reports and perhaps inform our future guidance, so please let me know (here or privately) if it ends up showing up as an issue in customer reports or not.

Sounds good.

 

> Will the blog post you mentioned be published prior to 133 beta (Jan 15)?

That's the goal, though DevRel hasn't confirmed a date. I'll check in with them.

Ok, thanks. If the blog post gets delayed, please hold off on extending the experiment to stable until the blog post is live.

Sounds good.

[Rick Byers]

LGTM1 to ship including a deprecation trial

On Fri, Nov 29, 2024, 5:00 p.m. François Doray <fdo...@google.com> wrote:

On Friday, November 29, 2024 at 3:13:39 PM UTC-5 Rick Byers wrote:

tl;dr: Just one remaining question about providing a developer opt-out (like a deprecation trial).

On Fri, Nov 29, 2024 at 12:25 PM Francois Pierre Doray <fdo...@chromium.org> wrote:

Hi Rick,

Thanks for raising your concerns regarding troubleshooting issues caused by Tab Freezing on Energy Saver.

> Does Chrome have any visual indication that a tab has been frozen?
There is no indication that a tab is frozen. However, the feature only operates when Energy Saver is active, signaled by a leaf icon next to the omnibox. When Energy Saver is first activated or when the leaf icon is clicked, a bubble indicates that "Background activity and some visual effects may be limited".

Ah cool, I had never noticed that before myself. I see there's also a prominent "turn off now" button:

 

That seems like a significant mitigation to me. If someone is having trouble with some site it seems like there's a decent chance that they (or their IT support people) would notice this indicator, click it, then click "turn off now" and confirm that fixes the issue. From there I'd imagine troubleshooting would be pretty easy (google searches for "chrome energy saver" would point to the per-site opt-out etc.)

We avoided a frozen tab indicator because in the long term (2-3 years), we plan to freeze most background tabs, to ensure that they don't steal resources from the foreground tab. At that point, there will be a visual indication for tabs that are not frozen (e.g. playing audio = speaker icon, using the progress notification API to do arbitrary work = UI TBD). 

I love that long-term plan, thanks! Personally I'd love to have a mode where pages get to run in the background only if they show such an icon or in response to me granting their origin that permission. That's not behind a flag or anything yet, right?

"Pages get to run in the background only if [they show some UI]" : In 2-3 years, we'd like this to be the default behavior, due to the expected foreground tab speed up and battery savings. It's not yet behind a flag.

> How discoverable is it for users that they can add a site to an exclusion list?

Users can add sites to the exclusion list via the "Performance" tab in Chrome settings (direct link: chrome://settings/performance), under "Always keep these sites active." This is also mentioned in the help article (will be updated for this launch).

Yeah I saw that, and I like that the UI contains a "current sites" list rather than requiring copying URLs. But that alone certainly is not discoverable for a user who simply has a broken web page and doesn't know why. But given that disabling energy saver is very discoverable, that's good enough for me as long as this is coupled just to energy saver. I guess you won't really have a way to measure how much site compat issues lead users to disable energy saver, eh? I imagine most users disabling it will do so for the performance / visual quality concerns, not site compat reasons.

We could run a HaTS survey to understand what leads users to add sites to the exclusion list. Let me know what you think and I can prioritize this.

It's not important for the launch process, so up to you. Not needed from my perspective.

While discoverability is limited, most users won't need this feature. Typical mail/chat/calendar/phone/drive/music streaming/videoconferencing/... apps will either not exceed the CPU threshold for freezing or be opted out via API usage. Sites requiring high background CPU usage under Energy Saver (outside of audio/video calls, device control...) can direct users to the Chrome settings page or recommend using this policy to enterprise admins (policy doc will be updated for this launch).

Yes I'm definitely convinced that "most" (probably even >99.99%) of users won't have a problem - your design is great for that, thank you! But what I've learned from my incident post-mortem responsibilities is that it's the ~0.0001% of users that we have to really focus on to reduce the risk of most OMGs. Ask Robert about why I'm afraid of his wrath around this next time you see him in the office :-).

Realistically I'd expect most such sites to just hack in some API usage that tickles your heuristic (like take an IndexedDB lock just for the purposes of being kept alive). That 's going to be much more effective for them than trying to direct users to take some manual steps, right? That seems unfortunate to me, as it will make your life harder in driving down the exceptions. Experience with this sort of thing is a big part of the motivation behind our guidance for providing explicit developer opt-outs for breaking changes (especially interventions like this). Sure, there is some risk of an explicit opt-out being abused but that risk isn't necessarily any greater than abuse of your heuristic, and at least you can more easily measure and track it and update behavior as necessary for any "arms race" with abusive sites. Have you considered offering developers a deprecation trial to reduce the risk of them abusing your heuristics and get you contact info for the developers who feel they must opt-out?

I hadn't considered a deprecation trial, but I think it's a good idea to reduce the risk of Web developers abusing our heuristics. In terms of process, should I create a "Feature removal" entry at chromestatus.com or can we handle this as part of this intent?

Great! Yeah we can just use this intent, no need for extra overhead. And of course it's important to document how to use the trial in the blog post.

 

We think that requiring some effort to allow high background CPU usage under Energy Saver is reasonable, as it can significantly impact battery life and contradicts Energy Saver's purpose (note: Energy Saver is only available on battery power, activates when battery level is below 20% by default).

I suspect that most impacted users would simply disable energy saver completely rather than make the extra effort to discover and use the site-specific opt-out. But that's fine - both settings aren't hard to find, and if you see a lot of users disabling energy saver then you can do some research to see if better per-site controls might help reduce that (though we might be stuck for the users who have already opted out completely). 

"though we might be stuck for the users who have already opted out completely": If we observe any significant difference in the number of Energy Saver activations between the Control/Enabled groups, or if we observe an upward trend of users without Energy Saver after the launch, we'll investigate why and make adjustments.

Oh of course, that makes sense - thanks!

[Vladimir Levin]

You've mentioned things like mail/calendar should still work. Is this because the expected background CPU usage is low or is it that it's using some API that directly opts it out of the freezing behavior? I'm particularly worried about things like calendar that don't _typically_ need to do any work, but _occasionally_ want to show a notification that you have an upcoming meeting. If there happens to be some background work happening in those that causes it to be frozen, that seems like it could be a hard to discover problem (due to the fact that it maybe only occasionally uses too much CPU) and quite painful for the user. In general, any site that can do background work and notifies the user via notifications seems like it could be problematic

Thanks,

Vlad

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fhohUewpp%3D_eeMcWEbQtZvBvLDNnnPT6eSAbdwxq8uA%40mail.gmail.com.

[Daniel Bratell]

Before "notifications" have been used as a signal of a page that wants to run in the background. I didn't see it listed here. The other use case that has been mentioned in similar threads is stock market applications which seem to both want to run in the background and do non-trivial work of some kind.

As for possible pitfalls I do wonder what happens on very slow or throttled computers where any work at all will be interpreted as "high cpu usage".

But I think this overall is a very reasonable feature for a browser. There will be challenges in, tuning, UI and user communication, but nothing that I consider a feature blocker.

LGTM2

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P1o1wBfdum060TnNmotmxoCFr0fEqKjjzUg%2BaepNijkw%40mail.gmail.com.

[Philipp Hancke]

what about WebSockets? Wondering about video conferencing websites that use Websockets as signaling transport to establish a WebRTC connection but do not open camera/microphone or the underlying connection until that is necessary.

(I do not expect such applications to use a lot of CPU in that state so might be fine)

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4086d432-7397-4bc5-9ba8-40f783428cf8%40gmail.com.

[Alex Russell]

Presumably we would want to treat Web Transport the same way as Web Sockets here, whatever we decide?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fhohUewpp%3D_eeMcWEbQtZvBvLDNnnPT6eSAbdwxq8uA%40mail.gmail.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+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P1o1wBfdum060TnNmotmxoCFr0fEqKjjzUg%2BaepNijkw%40mail.gmail.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+unsubscribe@chromium.org.

[François Doray]

Hi everyone,

Thanks for the feedback. Here are my responses:

1. An origin trial will allow Web developers to opt out of freezing. In addition to provide a quick way to prevent breakages, it will help us identify background use cases that might need dedicated APIs for support.

2. A blog post documenting the freezing policy and the origin trial will be published before the stable experiment.

3. I'm okay with adjusting the release schedule (e.g., "<10% in 133, 100% in 134") to help enterprise admins diagnose issues.

4. We'll track usage of the "Always keep these sites active" list in chrome://settings/performance. If usage increases significantly with freezing, we'll investigate and adjust accordingly. This list should be helpful to users with rare use cases, not a common solution.

5. Mail/chat/calendar apps shouldn't be affected, as the "high CPU usage" threshold will be significantly higher than their normal usage. If necessary, they can use the origin trial opt-out (short-term) or the Progress API (long-term) to declare CPU intensive workloads and avoid being frozen. They can also use the Push API to deliver notifications even when they aren't loaded, are crashed or are frozen (we're interested to learn about any hurdles preventing apps from adopting the Push API).

6. Tabs with notification permission will be opted out of freezing initially. We aim to remove this opt-out eventually, as notifications typically don't require high CPU usage. For high CPU needs, the origin trial (short-term) or the Progress API (long-term) are preferred solutions.

7. Pages with active WebRTC connections will be opted out, so videoconferencing apps will continue working, even if they don't capture from the camera/microphone/screen. No opt-out is planned for WebSockets or Web Transport, as they don't usually indicate CPU-intensive background functionality. The origin trial or Progress API can be used to avoid freezing despite running CPU-intensive workloads.

A note on the Progress API: We want the Progress API to be a good way for pages to declare their need for background resources (CPU/network) when other APIs (WebRTC, audio playback, Web USB, etc.) don't apply. It will be tied to UI (TBD) so that users remain in control. Besides opting out of freezing, usage of the API can increase CPU/network priority. We know some pages need background resources without having progress information (e.g., stock market dashboards, cryptocurrency miners). We'll ensure the Progress API (which might be renamed) covers these cases.

Have a nice day,

François

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fhohUewpp%3D_eeMcWEbQtZvBvLDNnnPT6eSAbdwxq8uA%40mail.gmail.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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P1o1wBfdum060TnNmotmxoCFr0fEqKjjzUg%2BaepNijkw%40mail.gmail.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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4086d432-7397-4bc5-9ba8-40f783428cf8%40gmail.com.

[Felipe Gomes]

Are there plans to exempt websites running/installed as a PWA from this?

[Francois Pierre Doray]

On Wednesday, December 11, 2024 at 3:11:04 PM UTC-5 Felipe Gomes wrote:

Are there plans to exempt websites running/installed as a PWA from this?

There are no plans to opt-out PWA from this. If a PWA needs to use a lot of CPU in the background when Energy Saver is active, it can use the same mechanisms as background tabs, i.e. origin trial opt-out (short-term) or the Progress API (long-term).

Energy Saver is a mode that users can rely on to extend battery life.  It's associated with UI indicating that it limits background activity and users can disable it. We want to provide ways for background web content to run CPU-intensive workloads under Energy Saver, but we don't want it to be the default, since that would make it too easy to inadvertently drain the battery with no user benefit. For example, we want to avoid scenarios in which web content continues unnecessary tasks in the background, like polling scroll position, due to missing code that stops these tasks when the content is hidden.

[Vladimir Levin]

LGTM3, thank you for the detailed explanation.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9c49e8db-6b7b-4dc2-8187-ff40a0bdf40en%40chromium.org.