Intent to Ship: Permissions Policy: focus-without-user-activation

[Fernando Fiori]

Contact emails

ekar...@chromium.org, icle...@chromium.org, mus...@chromium.org, ffi...@microsoft.com, leo...@microsoft.com

Explainer

https://github.com/ffiori/webappsec-permissions-policy/blob/focus-without-user-activation-explainer/policies/focus-without-user-activation.md

Specification

https://html.spec.whatwg.org/#focus-without-user-activation-feature

Summary

Gives embedders control over programmatic focus from embedded content via the `focus-without-user-activation` permissions policy. When the policy is denied for the initiating frame, programmatic focus changes (from `element.focus()`, `autofocus`, `window.focus()`, and the focusing steps for dialogs and popovers) are blocked unless that frame has transient user activation or focus is already within its subtree. This does not prevent dialogs or popovers from opening. User-initiated focus such as clicking or tabbing is never affected. The policy can be set via a `Permissions-Policy` HTTP response header or the iframe `allow` attribute. Focus delegation is supported: a parent frame that has focus can programmatically pass focus to a child iframe, even if the child has the policy denied, and once a frame has focus it can move focus within its own subtree.

Blink component

Blink>FeaturePolicy

Web Feature ID

Missing feature

Motivation

Embedded third-party content such as ads, widgets, and iframes can programmatically steal input focus from the top-level page without any user interaction, silently redirecting keystrokes and creating security and accessibility problems. This was originally reported by engineers working on advertising security for large publishers. Today developers have no reliable way to prevent it: the sandbox attribute disables JavaScript entirely, breaking most embedded content, and JavaScript focus-reclaiming hacks using blur listeners or polling are unreliable, cause visible focus flickering, and do not scale across multiple iframes. This policy provides fine-grained, declarative control over programmatic focus from embedded content.

Initial public proposal

https://github.com/w3c/webappsec-permissions-policy/issues/273

Search tags

focus-without-user-activation, focus, permissions policy

TAG review

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

TAG review status

Issues addressed

Origin Trial Name

focus-without-user-activation Permissions Policy

Goals for experimentation

Validate the current API design and get feedback on whether it satisfies developer needs in real life use cases.

Chromium Trial Name

BlockingFocusWithoutUserActivation

Link to origin trial feedback summary

https://groups.google.com/a/chromium.org/g/blink-dev/c/GLmp1IrJ4Ig/m/WSWz-Iv5AgAJ

Origin Trial documentation link

https://github.com/ffiori/webappsec-permissions-policy/blob/focus-without-user-activation-explainer/policies/focus-without-user-activation.md

WebFeature UseCounter name

kFocusWithoutUserActivationPolicySet

Risks

Interoperability and Compatibility

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1080)

WebKit: Support (https://github.com/WebKit/standards-positions/issues/406)

Web developers: Positive (https://github.com/w3c/webappsec-permissions-policy/issues/273) Several comments on that thread expressing web developer support.

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?

No impact on WebView applications. The policy shipping with a default of allow * would avoid breaking any webapp that uses focus APIs and make it an opt-in feature for web developers. Also the implementation has a base::Feature (BlockingFocusWithoutUserActivation) killswitch that can be flipped off in case of compat issues.

Debuggability

There are console messages when focus movement is blocked by this permissions policy to help developers debug their implementations related to this feature.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/permissions-policy/experimental-features?label=master&label=experimental&aligned&q=focus-without

Flag name on about://flags

blocking-focus-without-user-activation

Finch feature name

BlockingFocusWithoutUserActivation

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/40095111

Measurement

Added UseCounters FocusWithoutUserActivation*: FocusWithoutUserActivationAllowedByPolicy: https://chromestatus.com/metrics/feature/timeline/popularity/5873 FocusWithoutUserActivationAllowedByDescendant: https://chromestatus.com/metrics/feature/timeline/popularity/5874 FocusWithoutUserActivationBlocked: https://chromestatus.com/metrics/feature/timeline/popularity/5875 FocusWithoutUserActivationPolicySet: https://chromestatus.com/metrics/feature/timeline/popularity/5876 They were added in this CL: https://chromium-review.googlesource.com/c/chromium/src/+/7770268

Adoption expectation

Microsoft Teams has already adopted the `focus-without-user-activation` permissions policy and rolled it out in public preview. They're expected to use the feature by default as soon as it ships.

Adoption plan

Microsoft Teams has rolled out the policy in public preview and plans to enable it by default once it ships.

Estimated milestones

Shipping on desktop	158
Origin trial desktop first	149
Origin trial desktop last	152
Shipping on Android	158
Origin trial Android first	149
Origin trial Android last	152
Shipping on WebView	158
Origin trial WebView first	149
Origin trial WebView last	152

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5179186249465856?gate=4630319955705856

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69d6e35a.050a0220.1c79a0.0dc6.GAE%40google.com

This intent message was generated by Chrome Platform Status.

 

[Philip Jägenstedt]

https://wpt.fyi/results/permissions-policy/experimental-features/focus-without-user-activation-enabled.sub.html?label=master&label=experimental&aligned&q=focus-without is failing, does this test match the spec and if so is the plan to make it pass before shipping?

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH3PR00MB2480A0093FF93B090CE7DFDADC9D2%40CH3PR00MB2480.namprd00.prod.outlook.com.

[Fernando Fiori]

Thank you Philip for taking a look. Yes this test matches the spec, but it fails because blink blocks autofocus in cross-origin frames even when the policy is allowed. I'm working on updating the implementation to make this work, I will let you know when that's done and the test passes again.

Thanks,

Fernando

[Alex Russell]

LGTM1, pending test updates and such.

[Tom Jones]

not clear how this interfaces with w3c, but here are a few threats I found partly from AI.

• Keystroke Redirection & Phishing (Focus Theft): Embedded third-party content can silently pull focus away from the main page input fields. If a user is typing sensitive information (e.g., credentials, credit card numbers, or search queries), their keystrokes can be redirected into an embedded iframe or form without visual or immediate notice.
  1
  2
• Accessibility Disruption for Assistive Technologies: Screen readers and keyboard-only navigation depend heavily on stable focus. Unprompted focus changes forcibly relocate the reading or keyboard focus, confusing visually or mobility-impaired users and preventing them from navigating predictably.
  3
• Keyboard Navigation Hijacking: Users attempting to navigate forms or pages via keyboard shortcuts or Tab keys can be trapped or thrown off course if a script continually pulls focus back to a specific element.
  3
• UI Flickering & Performance Degradation: When multiple scripts or embedded frames aggressively run scripts (e.g., using element.focus(), window.focus(), or blur event polling) to reclaim or maintain focus, it results in visible screen flickering and erratic user interface behavior.
  1
  2
• Unwanted Modals & Dialog Interruptions: Scripts can force focus into programmatic popups or dialogs (dialog.showModal(), popover focusing, or autofocus), disrupting the workflow without any preceding user action or gesture.
  1

Also note that focus may become another threat with folding screens which now have an open possible with focus that could be major confusion.

Peace ..tom jones

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25748a7d-275a-450d-9a83-d3841faffa44n%40chromium.org.

[Fernando Fiori]

Thank you, Alex, for the LGTM!

Thomas, thanks for having a look. Those points you raise are precisely what this permissions policy aims to address. I tried to capture this in more detail in the explainer webappsec-permissions-policy/policies/focus-without-user-activation.md at ffiori/webappsec-permissions-policy. Let me know if you have any questions.

Fernando

[Mike Taylor]

This looks like a good feature. LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5ba5c44-fecb-4e8a-b579-4e607e9daa46n%40chromium.org.

[Fernando Fiori]

Thank you Mike for the LGTM!


Philip, following up on my earlier reply, I'd like to adjust the plan a little bit. The policy would still apply to autofocus, but I'd keep Chromium's existing cross-origin restriction in place for now. Authors could use the policy to further restrict otherwise permitted autofocus, but allowing it wouldn't override that restriction.

One of my main arguments was that a frame with the policy allowed could just call focus() anyway, but that argument misses scriptless cross-origin content, like a document with script-src 'none', or sanitized HTML that still includes autofocus.

I filed WHATWG #13105 to revisit whether this policy should lift the cross-origin autofocus restriction, and how the spec and tests should line up.

Under this plan, the autofocus assertion would still fail against the current spec for the initial rollout. Would you be comfortable moving ahead with the rest of the policy while we work through the autofocus question separately?


Thanks,
Fernando

[Yoav Weiss (@Shopify)]

LGTM3

[Mike Taylor]

I think that plan sounds fine, but can you please update the chromestatus entry to reflect what you'll be shipping (and won't be)?

[Fernando Fiori]

Thank you Yoav for the LGTM!

Mike, thanks for the suggestion, I just updated the summary and added the issue to the anticipated spec changes field.

And again, thank you all for your feedback.

Fernando