Contact emails

fer...@chromium.org, kenjibah...@chromium.org

Explainer

https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md

Specification

https://github.com/whatwg/html/pull/7915

Summary

A Permission-Policy for creating unload event listeners will be added.

Initially, the default policy will be set to allow. From there, Chrome will
gradually migrate the default policy to deny (i.e. increasingly disallow
the creation of unload event listeners, eventually reaching a state where
deny fully becomes the default policy). The ultimate goal is to remove
support for unload event.

Blink component

Blink>PermissionsAPI
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPermissionsAPI>

Motivation

The unload event is extremely unreliable. It is ignored in most cases by
all mobile browsers except Firefox on Android. Furthermore, in Safari, the
unload event is ignored on both desktop & mobile platforms.

In the current state, unload is a major BFCache blocker (~18 percentage
points reduction of hit rate for Chrome).

The change  will unlock a large fraction of that hit-rate while providing
an opt-out for those who need more time to migrate. It also sends a clear
signal that unload should not be used in new development.

Sidenote: the spec was changed to say that unload should only run if the
page cannot enter BFCache, which reflects Safari’s behavior, However
neither Chrome nor Mozilla have implemented this behavior. In Chrome's
case, we believe that this would suddenly break various sites and would
make it hard for developers to know if/when unload may run.


Initial public proposal

None

TAG review

https://github.com/w3ctag/design-reviews/issues/738

TAG review status

Pending

Risks

Interoperability and Compatibility

If no other browsers implement this, there is a risk that devs continue to
use unload widely and pages malfunction on chrome. However given that
alternatives to unload exist it seems entirely possible for sites that are
actively maintained to move off unload.

Gecko: (
https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320)
It's possible that pages are depending on `unload` handlers in subframes
for functionality even without any main frame navigation. We should try to
understand how common this is before breaking it. It should be possible to
measure how often subframe unloads fire when the mainframe is not
navigating. This will give us an upper bound on the size of the problem, -
Chrome: we have landed code to measure the occurrence of unload in
different scenarios. We will report back the findings.

WebKit: https://github.com/WebKit/standards-positions/issues/127

Web developers: Positive (
https://groups.google.com/a/chromium.org/g/bfcache-dev/c/zTIMx7u4uxo/m/-M4IS6LDBgAJ)
The web communities we reached out had positive reactions to our proposal
and we have not heard about any concrete blockers.

Other signals:

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?

On WebView, we will introduce the Permissions-Policy but not move the
default to "deny". BFCache does not work on WebView, so the benefit is
lower. Meanwhile the risk seems higher as we have far less visibility into
the HTML being run in WebViews. A roll-out to WebView should be done
independently and in consultation with the WebView team.


Debuggability

None

Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
?

Yes

Flag name

None

Requires code in //chrome?

False

Estimated milestones

M115 for availability of Permissions-Policy

M115 is the earliest we would start to disable unload, however

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5579556305502208

-- 
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLm7CR6EeL2KmBFyFpYT%3DNPXmTg4roLKV%3D7dRcCE%2BOoGwg%40mail.gmail.com.

Reply via email to