Contact emails [email protected], [email protected], [email protected], [email protected], [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 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. -- 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/69d6e35a.050a0220.1c79a0.0dc6.GAE%40google.com.
