Intent to Prototype: Conservative page freezing on desktop

[Francois Pierre Doray]

Contact emails

fdo...@chromium.org, shas...@chromium.org

Explainer

https://docs.google.com/document/d/1wAKlysswBe5GHxUjYNMfzdJTIIaHUm2nZAIOW1POw0I/edit?usp=sharing

Specification

https://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 component

Blink>Scheduling

Motivation

This is a first step towards "Efficient Background Tabs", 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?

No

Flag name

conservative-page-freezing (not implemented yet)

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1450304

Estimated milestones

Development will start in M116.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5158599457767424

[Michaela Merz]

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

[Francois Pierre Doray]

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). 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?

[Michaela Merz]

Thank you Francois. Here's an experience I'd like to share with you. I was watching and listening to a training presentation yesterday and was asked to look something up. So I opened a new tab to start looking it up. But the presentation in the first tab stopped and I was unable to use the second tab while receiving audio information from the first tab. This is NOT how the web should work (Chrome on a Chromebook).

I understand the good intention behind the proposal. And I *can* live with the idea of a page having a way of requesting continued access.  As a general rule though, I am concerned with all the "good intentions" which, in the end, often disregard valid use cases. After all, we, at the bottom of the development chain, can't always follow what would be "good practice". And I am afraid that you developers sometimes lack the imagination of what's really going on down here and how many hours and days we have to spend to keep our stuff running by circumventing yet another brilliant idea.

Michaela

[François Doray]

On Friday, June 2, 2023 at 1:02:39 PM UTC-4 Michaela Merz wrote:

Thank you Francois. Here's an experience I'd like to share with you. I was watching and listening to a training presentation yesterday and was asked to look something up. So I opened a new tab to start looking it up. But the presentation in the first tab stopped and I was unable to use the second tab while receiving audio information from the first tab. This is NOT how the web should work (Chrome on a Chromebook).

I agree that this is not how things should work. I encourage you to file a bug with the details on crbug.com and assign it to me. Conservative page freezing will not be applied to tabs with video/audio calls.

 

I understand the good intention behind the proposal. And I *can* live with the idea of a page having a way of requesting continued access.  As a general rule though, I am concerned with all the "good intentions" which, in the end, often disregard valid use cases. After all, we, at the bottom of the development chain, can't always follow what would be "good practice". And I am afraid that you developers sometimes lack the imagination of what's really going on down here and how many hours and days we have to spend to keep our stuff running by circumventing yet another brilliant idea.

We are open to refine the parameters of this policy to avoid breaking valid use cases. In some cases, we will prefer pointing the Web developer to ways of implementing their use case in a more resource-efficient way. Additionally, we plan to indicate in the UI when a tab is frozen and provide an option to opt-out a site from freezing. This will ensure that any site can keep working seamlessly without modification in a world with freezing.

 

Michaela

On Fri, Jun 2, 2023 at 10:38 AM Francois Pierre Doray <fdo...@chromium.org> wrote:

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). 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 misc...@googlemail.com 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 fdo...@chromium.org wrote:

Contact emailsfdo...@chromium.org, shas...@chromium.org

Explainerhttps://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

Motivation

This is a first step towards "Efficient Background Tabs", 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?No

Flag nameconservative-page-freezing (not implemented yet)

Requires code in //chrome?False

Tracking bughttps://crbug.com/1450304