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: > > [image: image.png] > > 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 > <https://github.com/explainers-by-googlers/progress-notification> 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 > <https://support.google.com/chrome/answer/12929150> (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 > <https://chromeenterprise.google/intl/en_ca/policies/#TabDiscardingExceptions> > 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 > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.glc7fyugcipe> > 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 > <https://www.chromium.org/blink/launching-features/#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! > > 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. > > > > Have a nice day, > > François > > On Wednesday, November 27, 2024 at 10:20:09 AM UTC-5 Rick Byers wrote: > > 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, 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 > <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+...@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/CAFUtAY9fhohUewpp%3D_eeMcWEbQtZvBvLDNnnPT6eSAbdwxq8uA%40mail.gmail.com.
