Intent to Experiment: Origin Trial Opt-Out/In for Page Freezing (desktop)

[François Doray]

Contact emails

fdo...@chromium.org, chr...@chromium.org

Spec

Specification: https://wicg.github.io/page-lifecycle/spec.html

Summary

Allow a page to opt-out/in of freezing via origin trial (desktop).

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/sotCDcI-E7Y/boghpXElDAAJ

Goals for experimentation

As of M79, we will freeze all freezable task queues of a page that has been backgrounded for 5 minutes, if the page is "freezable". To determine if a page is "freezable", Chrome will use heuristics described at Will my site be frozen? Additionally, we want to allow a page to opt-out/in of page freezing via origin trial. The goals are:

• Prevent breakages on sites that are not automatically opted-out by heuristics.

• Better understand how freezing affects the Web, via feedback collected from developers who register for the opt-out.

• Provide a way for sites that are opted-out via heuristics to opt-in and assess impact. GSuite is interested in trying this.

Experimental timeline

M79-M81

Will reassess the need for opt-out in M81, based on whether we were able to mitigate all the reasons why developers registered for the opt-out.

Any risks when the experiment finishes?

Before removing the origin trial opt-out, we will make sure that all sites that registered for it are either automatically opted-out via heuristics or have access to new APIs to provide their functionality in a freezing-friendly way (and had enough time to migrate to these APIs). Due to this, we don't expect problems when removing the origin trial opt-out.

Reason this experiment is being extended

n/a

Ongoing technical constraints

None

Debuggability

Web developers can verify whether their site is considered "freezable" and why by navigating to chrome://discards and hovering over the "Can freeze?" column. In particular, they can verify whether the opt-out/in is setup correctly on their site.

Freezing can be manually triggered and tested via chrome://discards.

A JS callback is emitted when the intervention is triggered.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

No.

Freezing already shipped on Android >1 year ago with no important breakages reported. There is no need to introduce an opt-out mechanism on that platform now.

There is a need to introduce a way to opt-out of freezing on desktop, because user expectations are different. In particular, users expect some pages to continue doing work when backgrounded.

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5193677469122560 

[Alex Russell]

LGTM

[François Doray]

We received feedback that setting up the freezing opt-out for 2 milestones without knowing what will happen afterwards is a lot of overhead.

We would like to extend the experimentation period until M90 (May 2021). That way, Web developers can be sure that their site will keep working without checking in too regularly. The WebComponents v0 deprecation trial also has a long experimentation period https://developers.chrome.com/origintrials/#/view_trial/2431943798780067841.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8fa6bec2-cb92-404d-b76e-e0f1b32233a9%40chromium.org.

[Michaela Merz]

Just to clarify - webdevs won't (for the time being) have to do anything to keep their background tabs active? I would very much appreciate this. Regardless of this, I would again ask you to re-consider the necessity of freezing/unloading tabs on non-battery powered devices. Shouldn't it be enough to de-prioritize backgrounded tabs so that they won't use a lot less in terms of CPU cycles?

Michaela

reduce

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[sligh...@chromium.org]

Hey all,

The OWNERs met today. My LGTM stands (thanks to Chris for answering questions about the reverse-OT mechanism). That said, a few points came up that probably need some response:

• We're going to make sure that standalone windows (PWAs) are exempted from this behavior, correct?
• The length of the reverse-OT is the subject of some concern. Our maximum to date has been 1 year for a heavily-used feature. Can we ensure that the length is capped at 1 year (or less) to start?
• Similarly, we'd like to understand usage through the course of the OT. Can the team commit to reporting back re: usage; say early on, then halfway through the r-OT? Number of OT registrations and (if possible) traffic fractions would be good to know.
• Do we understand what non-Chrome embedders are going to do here?

Regards

[François Doray]

We no longer intend to ship the feature controlled by this origin trial. See https://www.chromestatus.com/feature/5193677469122560. As a result, this Intent to Experiment is deprecated.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/efad92ff-47f9-4bd2-8480-3cb1126ad45e%40chromium.org.