Contact emails
fdo...@chromium.org, shase...@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 (eg 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 (eg 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 (eg links to known github issues in the project 
for the feature specification) whose resolution may introduce web 
compat/interop risk (eg, 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.

-- 
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+unsubscr...@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.

Reply via email to