html
html copied to clipboard
whatwg
Feature Policy: `focus-without-user-activation`
focus-without-user-activation is a new feature policy that can be used to block
programmatic programmatic focus changes that are not triggered through user activation
(explainer: https://github.com/w3c/webappsec-feature-policy/pull/304).
The motivation behind the change is to provide better security for websites that embed content from third parties (issue: https://github.com/w3c/webappsec-feature-policy/issues/273).
This change makes modifications to the following focus API
-
autofocus -
element.focus(options) -
window.focus()
:boom: Error: Wattsi server error :boom:
PR Preview failed to build. (Last tried on Jan 15, 2021, 7:59 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
:rotating_light: Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.
:link: Related URL
<html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx/1.10.3</center>
</body>
</html>
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.
This change makes modifications to the focus processing model such that for a new focus target that the policy is disabled (i.e., in its node document or its own document if the target is a browsing context):
- Focus steps runs as normal but the focusable area is not changed.
This does not appear to be what is done in this patch. Instead, attempts at focusing are entirely aborted; no focusing steps are run.
Agreed and sorry for misrepresentation. The initial attempt was to modify update focus steps but since the algorithm is invoked from different parts of the spec, and that we only care about the API (now mentioned in the description), I believe the current spec change is more relevant.
OK, this looks good to me spec-text wise. What remains before we can merge this is multi-implementer interest, and web platform tests.
Thanks! I will be adding tests for this soon. I have a Chromium CL for that.
@annevk Would you be able to review this change?
If the default is not blocking for third-party contexts, this seems like a sandboxing feature, in which case it'll be affected by the planned changes to Feature Policy, right?
@ehsan-karamad it appears you force-pushed over my nit fixes, e.g. adding the word "feature" after feature names :(.
Also, @ehsan-karamad, you work for Google, which is in the field of web technologies, so it's not appropriate to sign the Participant Agreement as an individual. Instead you need to make your membership in the Google organization public.
Also, @ehsan-karamad, you work for Google, which is in the field of web technologies, so it's not appropriate to sign the Participant Agreement as an individual. Instead you need to make your membership in the Google organization public.
Thanks. I didn't know it is private by default actually. I made it public. I wouldn't mind un-signing the agreement as an individual if that is a thing.
If the default is not blocking for third-party contexts,
Yes, for now, we are thinking about making this blocking by default in sandboxed subframes. But that said,
it should perhaps be disabled for third-party contexts as well (treat like permissions?). The argument for
it is that the spec for autofocus actually blocks focus when requested by cross-origin.
this seems like a sandboxing feature, in which case it'll be affected by the planned changes to Feature Policy, right?
Yes. If there is no default enforcement to third party, sandbox flag might be the best fit and it will be definitely affected by how Feature Policy is changed.
No worries! Could you push an additional commit which ensures that all instances say allowed to use the "x" feature, instead of sometimes allowed to use the "x" or allowed to use "x"?
I've deleted your individual agreement submission; all is good there.
No worries! Could you push an additional commit which ensures that all instances say
allowed to use the "x" feature, instead of sometimesallowed to use the "x"orallowed to use "x"?
Done. I pushed a change (not force this time) :).
I've deleted your individual agreement submission; all is good there.
Thanks!
Marked "do not merge yet" as we need to figure out if this is permission-like (disabled in third party contexts unless this is set, enabled otherwise) or sandbox-like (can be disabled anywhere).
cc @clelland
Given that <input autofocus> is currently not expected to work in any cross-origin cases, per spec, I'd love to see programmatic focus-without-user-activation follow the same model (permission-like) so that it can't be used as a way around that restriction. So not just sandboxes, but all third-party content, unless delegated by the parent document.
I don't know yet how web-compatible that change would be, but that's where I would like to see this end up.
Just to make it explicit, is the idea to keep this PR open until there's multi-vendor support, or also until the change is proven web compatible by shipping it? @annevk, on the multi-vendor support front, who at Mozilla can speak to this?
Aside: the autofocus attribute plus programmatic element.focus() following the same rules is great, and analogous to media autoplay.
Oops, I spoke to soon in my aside. The proposal says
"focus-without-user-activation", which has a default allowlist of *.
That doesn't match the behavior of the autofocus attribute. Shouldn't the default allowlist be 'self'? If not, there is no web compat concern, so I suspect this is an oversight?
That doesn't match the behavior of the
autofocusattribute. Shouldn't the default allowlist be 'self'? If not, there is no web compat concern, so I suspect this is an oversight?
I think this matches @clelland 's suggestion above and would place this policy along with the other permission-like policies.
What's the state of this policy? Is there any plan to merge this or has the discussion moved somewhere else?
I'd love to be able to ship this; there's a bit more discussion on https://github.com/w3c/webappsec-permissions-policy/issues/273. Maybe 2024 is its year!
