I evaluated this intent relative to our compat principles <https://bit.ly/blink-compat> 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 <https://support.google.com/chrome/a/answer/7679408?hl=en&co=CHROME_ENTERPRISE._Product%3DChromeBrowser#top:~:text=131%20on%20Android-,Tab%20freezing%20on%20Energy%20saver,-When%20Energy%20saver> in Chrome 131 enterprise release notes already, thank you! Thanks, Rick On Tue, Nov 26, 2024 at 3:11 PM Chromestatus < ad...@cr-status.appspotmail.com> wrote: > 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 > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling> > > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? 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 > <https://chromestatus.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+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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67462b62.2b0a0220.19a388.0546.GAE%40google.com?utm_medium=email&utm_source=footer> > . > -- 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/CAFUtAY-Og6p6bLrvT0QuLWuYW%2B4DT04AOe44SSSRkg6gp7L6jQ%40mail.gmail.com.
