Feature Policy: `focus-without-user-activation` #4585

ehsan-karamad · 2019-04-30T22:49:49Z

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: w3c/webappsec-permissions-policy#304).

The motivation behind the change is to provide better security for websites that embed
content from third parties
(issue: w3c/webappsec-permissions-policy#273).

This change makes modifications to the following focus API

autofocus
element.focus(options)
window.focus()

💥 Error: Wattsi server error 💥

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:

🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

🔗 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.

ehsan-karamad · 2019-05-06T16:18:22Z

@marian-r and @clelland FYI.

domenic

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.

domenic · 2019-05-08T15:24:45Z

source

@@ -53257,6 +53260,11 @@ form.method === input; // => true</code></pre>
   <li><p>If <var>target</var>'s <span>active sandboxing flag set</span> has the
   <span>sandboxed automatic features browsing context flag</span>, then return.</p></li>

+   <li><p>If this algorithm is not <span>triggered by user activation</span> and the
+   policy-controlled feature "<code
+   data-x="focus-without-user-activation-feature">focus-without-user-activation</code>" is disabled


It looks like the correct verbiage here is

<var>target</var> is not <span>allowed to use</span> the "<code data-x="focus-without-user-activation-feature">focus-without-user-activation</code>" feature

Cf. https://html.spec.whatwg.org/#playing-the-media-resource:allowed-to-use

Thanks for pointing this out. Done.

domenic · 2019-05-08T15:26:10Z

source

+   <li><p>If this algorithm is not <span>triggered by user activation</span> and the
+   policy-controlled feature "<code
+   data-x="focus-without-user-activation-feature">focus-without-user-activation</code>" is disabled
+   in <var>current</var>'s <span>active document</span>, return.</p></li>


Additional nit: we're slowly moving toward using "then" for new if statements, so "then return". (Like the previous bullet.)

ehsan-karamad · 2019-05-08T19:30:43Z

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.

domenic

OK, this looks good to me spec-text wise. What remains before we can merge this is multi-implementer interest, and web platform tests.

ehsan-karamad · 2019-05-09T19:39:40Z

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?

annevk · 2019-05-10T07:35:47Z

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?

domenic · 2019-05-10T13:40:53Z

@ehsan-karamad it appears you force-pushed over my nit fixes, e.g. adding the word "feature" after feature names :(.

My fixes got lost so now there are still nits to fix

domenic · 2019-05-10T13:52:47Z

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.

ehsan-karamad · 2019-05-10T14:29:02Z

ames :(.

Uh very sorry! I still need to find my way around github.

ehsan-karamad · 2019-05-10T14:30:21Z

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.

ehsan-karamad · 2019-05-10T14:42:01Z

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.

domenic · 2019-05-10T15:25:51Z

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.

ehsan-karamad · 2019-05-10T16:59:42Z

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"?

Done. I pushed a change (not force this time) :).

I've deleted your individual agreement submission; all is good there.

Thanks!

annevk · 2019-05-14T12:05:42Z

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

clelland · 2019-05-17T18:36:18Z

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.

foolip · 2019-06-05T08:18:12Z

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.

foolip · 2019-06-05T08:30:22Z

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?

ehsan-karamad · 2019-06-05T13:49:12Z

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?

I think this matches @clelland 's suggestion above and would place this policy along with the other permission-like policies.

omarjcamo · 2023-10-09T15:13:03Z

What's the state of this policy? Is there any plan to merge this or has the discussion moved somewhere else?

clelland · 2023-12-21T16:22:18Z

I'd love to be able to ship this; there's a bit more discussion on w3c/webappsec-permissions-policy#273. Maybe 2024 is its year!

Cherry-picked from whatwg#4585

siliu1 · 2024-10-03T17:41:14Z

I don't have editor access to this PR. So I've created #10672 to continue the work to ship this.

ehsan-karamad force-pushed the spec_focus_clean branch from f611320 to e74637e Compare May 1, 2019 14:02

Spec change for focus without activation

8e312f2

ehsan-karamad force-pushed the spec_focus_clean branch from e74637e to 8e312f2 Compare May 6, 2019 15:50

ehsan-karamad changed the title ~~[WIP] Spec change for focus-without-use-activation~~ [WIP] Feature Policy: focus-without-user-activation May 6, 2019

ehsan-karamad marked this pull request as ready for review May 6, 2019 16:16

ehsan-karamad changed the title ~~[WIP] Feature Policy: focus-without-user-activation~~ Feature Policy: focus-without-user-activation May 7, 2019

domenic requested changes May 8, 2019

View reviewed changes

Use the right verbiage for policy

a4d70ee

domenic added needs implementer interest Moving the issue forward requires implementers to express interest needs tests Moving the issue forward requires someone to write tests labels May 9, 2019

domenic previously approved these changes May 9, 2019

View reviewed changes

use 'allow to use the ... feature' pattern

80db01d

annevk added the do not merge yet Pull request must not be merged per rationale in comment label May 14, 2019

jihyerish mentioned this pull request May 30, 2019

[css-nav-1] Keeping related feature policies consistent accross the web platform. w3c/csswg-drafts#3656

Open

domenic mentioned this pull request Sep 24, 2019

Prevent programmatic focus in iframe #4326

Open

Base automatically changed from master to main January 15, 2021 07:57

domenic force-pushed the main branch from 0947339 to 1b5099f Compare July 27, 2021 17:07

This comment was marked as spam.

Sign in to view

siliu1 mentioned this pull request Sep 19, 2024

Prevent programmatic focus in iframe w3c/webappsec-permissions-policy#273

Open

sanketj mentioned this pull request Sep 20, 2024

TPAC 2024 meeting whatwg/meta#326

Closed

siliu1 added a commit to siliu1/html-fork that referenced this pull request Oct 1, 2024

Spec change for focus-without-user-activation

ce00f26

Cherry-picked from whatwg#4585

This was referenced Oct 1, 2024

focus-without-user-activation feature policy WebKit/standards-positions#406

Open

focus-without-user-activation feature policy mozilla/standards-positions#1080

Open

Feature Policy: focus-without-user-activation #10672

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature Policy: `focus-without-user-activation` #4585

Feature Policy: `focus-without-user-activation` #4585

ehsan-karamad commented Apr 30, 2019 •

edited by pr-preview bot

Loading

ehsan-karamad commented May 6, 2019

domenic left a comment

domenic May 8, 2019

ehsan-karamad May 9, 2019

domenic May 8, 2019

ehsan-karamad May 9, 2019

ehsan-karamad commented May 8, 2019

domenic left a comment

ehsan-karamad commented May 9, 2019

annevk commented May 10, 2019

domenic commented May 10, 2019

domenic commented May 10, 2019

ehsan-karamad commented May 10, 2019

ehsan-karamad commented May 10, 2019

ehsan-karamad commented May 10, 2019

domenic commented May 10, 2019 •

edited

Loading

ehsan-karamad commented May 10, 2019

annevk commented May 14, 2019

clelland commented May 17, 2019

foolip commented Jun 5, 2019

foolip commented Jun 5, 2019

ehsan-karamad commented Jun 5, 2019

omarjcamo commented Oct 9, 2023

clelland commented Dec 21, 2023

This comment was marked as spam.

siliu1 commented Oct 3, 2024

Feature Policy: focus-without-user-activation #4585

Are you sure you want to change the base?

Feature Policy: focus-without-user-activation #4585

Conversation

ehsan-karamad commented Apr 30, 2019 • edited by pr-preview bot Loading

💥 Error: Wattsi server error 💥

ehsan-karamad commented May 6, 2019

domenic left a comment

Choose a reason for hiding this comment

domenic May 8, 2019

Choose a reason for hiding this comment

ehsan-karamad May 9, 2019

Choose a reason for hiding this comment

domenic May 8, 2019

Choose a reason for hiding this comment

ehsan-karamad May 9, 2019

Choose a reason for hiding this comment

ehsan-karamad commented May 8, 2019

domenic left a comment

Choose a reason for hiding this comment

ehsan-karamad commented May 9, 2019

annevk commented May 10, 2019

domenic commented May 10, 2019

domenic commented May 10, 2019

ehsan-karamad commented May 10, 2019

ehsan-karamad commented May 10, 2019

ehsan-karamad commented May 10, 2019

domenic commented May 10, 2019 • edited Loading

ehsan-karamad commented May 10, 2019

annevk commented May 14, 2019

clelland commented May 17, 2019

foolip commented Jun 5, 2019

foolip commented Jun 5, 2019

ehsan-karamad commented Jun 5, 2019

omarjcamo commented Oct 9, 2023

clelland commented Dec 21, 2023

This comment was marked as spam.

siliu1 commented Oct 3, 2024

Feature Policy: `focus-without-user-activation` #4585

Feature Policy: `focus-without-user-activation` #4585

ehsan-karamad commented Apr 30, 2019 •

edited by pr-preview bot

Loading

domenic commented May 10, 2019 •

edited

Loading