I fully agree with this statement: "the general idea of the web is to let the users decide whether or not they like a page or app".
I'd like to take a step back and share a high-level view of what we're trying to accomplish. First, a few observations based on our analysis of field data, local data and user research: - Background tabs play a role in slowing down the foreground activity, discharging the battery, spinning the fan and OOM crashes. - The majority of the work performed by background tabs is wasteful (just one example: a page keeps periodically appending scroll position to an array for analytics purposes while backgrounded). - There are background tabs which perform work that is valuable to the user (e.g. periodic weather radar updates, uploading files to the cloud, processing a large dataset...). - It is difficult for both users and Web developers to know when a background tab degrades the user experience and to address the problem. Based on these observations, we believe: - By default, most background pages should be frozen. This solves the problem of pages unintentionally degrading user experience through their background resource usage. - However, a page that *wants *to keep running in the background should be able to declare it through a Web platform API (to be defined). The user agent can surface that to the user and provide controls to disallow it (inspirational mocks <https://docs.google.com/document/d/1W_AIebegAf0wTHtbURgsataYWGT-VCJsvlqo_UzMZOs/edit#bookmark=id.218p2g1lkd50>). Unless the user disallows the background work, the user agent shouldn't freeze the background page (nor deprioritize its CPU and network usage or make it a candidate for discarding as it does today). - In this end state, users can more easily "decide whether or not they like a page or app" than today. The idea behind "Conservative Page Freezing" is that with sufficiently generous allowances, we can eliminate the most egregious cases of wasteful background resource consumption without breakages and without waiting for the aforementioned Web platform API. I'm curious if significantly increasing the allowances (currently proposed: 15 minutes grace period, afterwards: 50ms of execution / 5 minutes) would address your concerns? On Wednesday, May 31, 2023 at 5:37:33 PM UTC-4 [email protected] wrote: > We are categorically against this. It severely limits developers to what > is considered to be "good practice" which is not always desired (or > possible), especially not in complex environments. We are frankly getting > tired to be told what is "good" and what is "bad" behavior without any > consideration of our special use cases. Sure - we may find work arounds, > but the general idea of the web is to let the users decide whether or not > they like a page or app (unless there are security considerations). > > I can think of a number of services that may be interrupted like > periodical weather radar updates, long ajax downloads or other > communications over ajax as well as other complex background tasks. > > As it has been mentioned before, web developers expressed concerns about > background page freezing. This alone should give you pause. There is > nothing "conservative" about this proposal. It is going to break things. > And breaking things should NOT be what y'all doing. > > Michaela > > > > > > > On Wednesday, May 31, 2023 at 12:17:59 PM UTC-6 [email protected] wrote: > >> Contact [email protected], [email protected] >> > >> >> Explainer >> https://docs.google.com/document/d/1wAKlysswBe5GHxUjYNMfzdJTIIaHUm2nZAIOW1POw0I/edit?usp=sharing >> >> Specificationhttps://wicg.github.io/page-lifecycle >> >> Summary >> >> On a page that has been hidden and silent for >15 minutes, each agent can >> execute for 50ms per 5 minutes interval. After an agent has exhausted its >> execution budget, it is frozen until the beginning of the next 5 minutes >> interval, unless: - It holds a Web Lock or an IndexedDB transaction which >> contends with another non-frozen page/worker. - It captures from a >> microphone, camera or screen/window/tab. - It has an RTCPeerConnection with >> an 'open' RTCDataChannel or a 'live' MediaStreamTrack. - It uses Web USB, >> Web Bluetooth, Web HID or Web Serial. - It received a message (postMessage) >> from another page/worker in the last 50ms. A frozen agent may be unfrozen >> if it starts meeting one of these conditions (e.g. Web Lock held by a >> frozen agent is requested by another agent). State transitions will happen >> as defined in the page lifecycle API. This proposal is for desktop >> platforms. On Android, pages are frozen after 5 minutes in the background >> since M68 (https://chromestatus.com/feature/4639097628917760). >> >> Blink componentBlink>Scheduling >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling> >> >> Motivation >> >> This is a first step towards "Efficient Background Tabs >> <https://docs.google.com/document/d/1W_AIebegAf0wTHtbURgsataYWGT-VCJsvlqo_UzMZOs/edit?usp=sharing>", >> >> which aims to eliminate negative impact on user experience from background >> tabs. >> >> Risks >> >> Interoperability and Compatibility >> >> It's fine if a browser does not freeze background pages. However, if a >> browser does freeze background pages, complying with the Page Lifecycle >> spec lets pages handle the state transition consistently across browsers. >> >> *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 background page freezing, because it made it difficult to >> implement background functionality that users care about in a reliable way >> (e.g. notification for calendar event). Heuristics in this *conservative* >> page freezing proposal should prevent breakages that were reported in past >> proposals (e.g. 50ms of execution time per 5 minutes is sufficient to >> execute a timer which shows a calendar event notification). Additionally, >> we will listen to Web developers feedback on multiple channels (crbug, >> blink-dev, stack overflow, twitter, github) and make adjustments to >> heuristics (or refer Web developers to well-established best practices) if >> we find that background functionality that users care about is broken. >> >> *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 freezes pages before putting them in the BFCache. - 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 special handling is required for browsers which don't freeze pages. >> >> Security >> >> Freezing decisions are taken independently for each agent, to prevent an >> agent from learning about the execution time or features used by another >> agent. >> >> 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 proposal is for desktop only. It does not affect WebView. >> >> >> >> Debuggability >> >> DevTools > Application > Background Services will expose the frozen state >> of each agent and the underlying reasons. It will also provide a mechanism >> to override the frozen state. >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?No >> >> Flag nameconservative-page-freezing (not implemented yet) >> >> Requires code in //chrome?False >> >> Tracking bughttps://crbug.com/1450304 >> >> Estimated milestones >> >> Development will start in M116. >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5158599457767424 >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6d5855f-f470-42dd-9302-6765750185aen%40chromium.org.
