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 < bratel...@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+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 >> <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+unsubscr...@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+unsubscr...@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/CADxkKiJD0sQ7ACFFUZ90jrNOELtmyR9U%3DMU%2Bm2AOax7npD-tag%40mail.gmail.com.
