Contact emails [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>
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<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EFeaturePolicy%22> 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<https://chromestatus.com/features#tags:focus-without-user-activation>, focus<https://chromestatus.com/features#tags:focus>, permissions policy<https://chromestatus.com/features#tags:permissions%20policy> 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<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? 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<https://chromestatus.com/>. -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH3PR00MB2480A0093FF93B090CE7DFDADC9D2%40CH3PR00MB2480.namprd00.prod.outlook.com.
