Hi Fergal,
Nice to have lunch with you today.
On 6/28/23 5:06 PM, 'Fergal Daly' via blink-dev wrote:
Hi API-owners,
I am now asking for permission to go ahead with the following concrete
unload deprecation plan below.
*
Tools and outreach
o
M115 Enable `Permission-Policy: unload` (PP:unload) with the
default being enabled. This allows sites to opt-in to unload
deprecation.
o
Outreach to 1st/3rd parties, to migrate away from using unload
and to enforce this with PP:unload.
*
Deprecation
o
M117 change the default for PP:unload so that unload handlers
are skipped by default for 1% of page loads
o
M118 increase to 5% of page loads
o
M119 (last of 2023) increase to 10% of page loads
o
Evaluate progress on reduction of the use of unload
o
M120-128 increase +10% gradually to 100% of page loads
Enterprise policy would allow opt-out entirely.
Obviously, the deprecation timeline is contingent on unload usage
coming down in response to the earlier steps.
Can you spell out a bit more what you're thinking here? I wouldn't
expect much movement when enabled at only 1% (but maybe y'all are super
good at outreach and will prove me wrong) - it's very likely losing 1%
of unload handlers is hard to notice or reproduce (my hunch is that
"breakage" here is subtle, and in the form of missing analytics/pings,
etc.). 5% is probably a big enough dent to notice, maybe?
I would almost recommend getting to 5% faster than M119 - that's just a
few weeks out from November holidays where many sites go into code
freeze ahead of Black Friday™.
We expect that 10% of page loads will provide a noticeable signal to
sites that use unload. Also, if we were to just follow the current
spec and not run unload when we can BFCache (as happens on
Clank/Firefox mobile and all WebKit) we expect that we would skip
30-40% of unload handlers when the main frame navigates.
Decisions:
*
Timeline
*
All navigations vs main-frame navigations only
Standardising
We have some new data and have had some further discussions with
browser vendors. There's no consensus. TL;DR WebKit are opposed to any
Permissions-Policy but support removing unload eventually. Mozilla are
still discussing.
Both Mozilla
<https://github.com/mozilla/standards-positions/issues/691>and WebKit
<https://github.com/WebKit/standards-positions/issues/127>were opposed
to standardising `Permissions-Policy: unload` (defaulting to on)
because they worried that a containing frame might selectively disable
unload handlers in a child frame for malicious purposes (no specific
cases were discussed).
So we flipped to the idea of having PP:unload with the default being
disabled. We cannot suddenly do that. We need to roll it out
gradually. WebKit folks are opposed to this and have suggested
<https://github.com/WebKit/standards-positions/issues/200#issuecomment-1596385073>we
do a reverse origin trial instead. If our plan works out, eventually
we would ROT as the final nail but ROT starting now has downsides for
users and sites and no upside for the implementer.
Mozilla has so far not been negative
<https://github.com/mozilla/standards-positions/issues/691>on the
Permissions-Policy off-by-default approach but they are still
discussing. They are concerned that disabling unloads when subframes
are navigating could be a problem. We found that about 1/4 of subframe
navigations involve an `unload` handler (most seem to involve handlers
in cross-site and same-site site frames). We don't have examples of
sites that rely on `unload` handlers in this way, although they
probably do exist. Migrating to `pageshow` or using PP:unload for
these sites should be trivial.
We have the option to say that PP:unload only applies to main frame
navigations. This would mean these sites would be completely
unaffected however that has some downsides. It is harder to explain
and does not end with full removal of `unload`. We would prefer to
have this apply to all navigations unless we find a good reason not
to. If we were to change part-way, there would be no breakage. We hope
that once we drive down usage in 3rd-part iframes with PP:unload that
the number of unload handlers running in subframe navigations
decreases significantly.
Finally there was some discussion
<https://github.com/w3c/webappsec-permissions-policy/issues/513#issuecomment-1564361739>about
how Permissions-Policy off-by-default should work. Our current version
requires every page to set the header and every parent to set the
iframe `allow` attribute. This is maximally conservative. If at some
point later on there is agreement to standardise on something less
conservative, it will not break pages that have already re-enabled
`unload`.
Overall it seems hard to standardise in advance but if we succeed in
driving down `unload` usage, other browsers are on-board with removing
unload. The worst case scenario would be where we implement PP:unload
(which the others do not agree with) but make no noticeable progress
on `unload` usage. If that happens we can just go with the currently
specced behaviour (don't run `unload` if BFCaching is possible) and
maybe revert the PP:unload,
F
On Tue, 9 May 2023 at 16:01, Fergal Daly <fer...@google.com> wrote:
On Mon, 8 May 2023 at 17:51, Rick Byers <rby...@chromium.org> wrote:
Hi Fergal,
It's exciting to see this moving forward! Just to clarify,
this is effectively an I2S for the unload permissions-policy,
is that right? Or are you also requesting permission to stop
firing unload events now too? The latter is going to require
some significant compat analysis, but could be greatly
informed by the experience of having some top-level sites
opt-out of unload for their frame tree.
Thanks.
We're not requesting permission to stop firing at this point. It
is the far-away end-point.
Any plan to trigger a deprecation warning / report for the
installation of unload handlers? It might be tricky to find a
good balance of useful warnings without being too spammy.
Permission policy will do this as is with a console warning and
Reporting-API if you attempt to install a handler that is
disallowed by policy.
A couple more questions / comments inline:
On Mon, May 8, 2023 at 7:43 AM Fergal Daly
<fer...@chromium.org> wrote:
Contact emails
fer...@chromium.org, kenjibah...@chromium.org
Explainer
https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md
<https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md>
Specification
https://github.com/whatwg/html/pull/7915
<https://github.com/whatwg/html/pull/7915>
This is still marked as draft. Can you get this ready for
review? If it's blocked only on having a 2nd implementor show
support, then I'd be fine shipping based on a PR. But we
should at least do what we can to solicit feedback on the spec
change prior to shipping.
Yes. There's nothing in the spec change that isn't in the requests
for positions but since neither of those are supportive yet, I
have not asked for review of the PR. I'm hopeful that once we have
data on use on unload in subframe navigations as discussed here
<https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320>
that
Mozilla will be supportive. Those metrics are in 113 but based on
the data from beta, we need to change how we record them.
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
denyfully 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
<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
<https://github.com/WebKit/standards-positions/issues/127>
From a quick skim, it sounds like WebKit is already happy with
their tradeoff of not firing unload and doesn't see a need for
an API that reduces unload further, is that about right?
WebKit has mostly shipped heuristics here without trying to
spec them first, right? In general I'm not too concerned
Yes, there's no great upside for them. I believe the situation as
specced where unload is unpredictable and likely biased is bad for
devs and is probably skewing data collected via WebKit (and
Chrome/Mozilla mobile) but nobody is complaining.
I believe there was support expressed offline for the prospect of
killing off unload.
Web developers: Positive
(https://groups.google.com/a/chromium.org/g/bfcache-dev/c/zTIMx7u4uxo/m/-M4IS6LDBgAJ
<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.
Sounds like the right strategy to me, thanks!
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
Please put the new policy behind a RuntimeEnabledFeature
<https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md>.
It's effectively a new API so is required
<https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required>
to have a finch killswitch. It sounds to me like it should be
unlikely that simply adding the new policy could break things,
but maybe some scenario is possible where we decide breakage
in 3p iframes is bad enough to warrant an emergency fix?
Yes, there will be a flag, maybe more than one. The implementation
details of rolling this out gradually have not been worked out.
See below.
Requires code in //chrome?
False
Estimated milestones
M115 for availability of Permissions-Policy
M115 is the earliest we would start to disable unload,
however
Is this a typo? Or are you considering disabling the event in
the same release we first make the permissions policy available?
The plan is to make the PP available with a default of enabled and
then gradually flip the default to disabled. The details are here
<https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md#logistics-of-deprecation>.
It's not particularly nice. We have the option to just stop 100%
but that seems fairly disruptive,
F
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5579556305502208
<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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLm7CR6EeL2KmBFyFpYT%3DNPXmTg4roLKV%3D7dRcCE%2BOoGwg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/CAAozHLnTtwL9jbt0gyS%3DDouUk2yzsHrmgmF7YaDasb-%2B706EOQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLnTtwL9jbt0gyS%3DDouUk2yzsHrmgmF7YaDasb-%2B706EOQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/d371536a-38db-8dc2-50aa-ffdb5c671e50%40chromium.org.
