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

[Chromestatus]

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 a frame, programmatic focus calls (element.focus(), autofocus, window.focus(), dialog.showModal(), and popover focusing) are blocked unless triggered by user activation. 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

No information provided

Search tags

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

TAG review

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

TAG review status

Issues addressed

Goals for experimentation

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

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.

Ongoing technical constraints

None.

Debuggability

Planning to add console messages when focus movement is blocked by this permissions policy to help developers debug their implementations related to this feature. CL in progress here: https://chromium-review.googlesource.com/c/chromium/src/+/7734991

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

Requires code in //chrome?

False

Tracking bug

https://crbug.com/40095111

Estimated milestones

Shipping on desktop	150
Origin trial desktop first	148
Origin trial desktop last	150
Shipping on Android	150
Origin trial Android first	148
Origin trial Android last	150
Shipping on WebView	150
Origin trial WebView first	148
Origin trial WebView last	150

Link to entry on the Chrome Platform Status

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

This intent message was generated by Chrome Platform Status.