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/e1e27411-a280-412d-9c4b-33b95ca75072n%40chromium.org.
