Are there plans to exempt websites running/installed as a PWA from this? On Wednesday, December 11, 2024 at 3:20:49 PM UTC-3 François Doray wrote:
> 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 <https://github.com/explainers-by-googlers/progress-notification> > (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 > <https://github.com/explainers-by-googlers/progress-notification> (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 > <https://github.com/explainers-by-googlers/progress-notification>: 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 > > On Wednesday, December 11, 2024 at 11:12:14 AM UTC-5 Alex Russell wrote: > >> Presumably we would want to treat Web Transport the same way as Web >> Sockets here, whatever we decide? >> >> On Sunday, December 8, 2024 at 12:20:50 PM UTC-8 >> philipp...@googlemail.com wrote: >> >>> 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) >>> >>> Am Mi., 4. Dez. 2024 um 06:34 Uhr schrieb Daniel Bratell < >>> brat...@gmail.com>: >>> >> 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 >>>> On 2024-12-04 03:45, Vladimir Levin wrote: >>>> >>> 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 >>>> >>>> On Fri, Nov 29, 2024 at 7:38 PM Rick Byers <rby...@chromium.org> wrote: >>>> >>>> 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+...@chromium.org. >>>> >>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fhohUewpp%3D_eeMcWEbQtZvBvLDNnnPT6eSAbdwxq8uA%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fhohUewpp%3D_eeMcWEbQtZvBvLDNnnPT6eSAbdwxq8uA%40mail.gmail.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+...@chromium.org. >>>> >>>> >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P1o1wBfdum060TnNmotmxoCFr0fEqKjjzUg%2BaepNijkw%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P1o1wBfdum060TnNmotmxoCFr0fEqKjjzUg%2BaepNijkw%40mail.gmail.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+...@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 >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4086d432-7397-4bc5-9ba8-40f783428cf8%40gmail.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/2e37a7da-a26d-4ca7-80f0-f9c99135aae3n%40chromium.org.
