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 <https://github.com/ffiori/webappsec-permissions-policy/blob/focus-without-user-activation-explainer/policies/focus-without-user-activation.md>. Let me know if you have any questions.
Fernando On Monday, October 19, 2026 at 4:19:14 PM UTC-7 [email protected] wrote: > 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 <https://chromestatus.com/feature/5179186249465856> > 2 > > <https://mail.google.com/mail/u/0/#all/%23thread-f:1879048351712254581%7Cmsg-f:1879503045256153924> > - *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 > > <https://www.webaccessibility.com/resource-library/best-practice/?bestPractice=801> > - *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 > > <https://www.webaccessibility.com/resource-library/best-practice/?bestPractice=801> > - *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 <https://chromestatus.com/feature/5179186249465856> > 2 > > <https://mail.google.com/mail/u/0/#all/%23thread-f:1879048351712254581%7Cmsg-f:1879503045256153924> > - *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 <https://chromestatus.com/feature/5179186249465856> > > 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 > > > On Mon, Oct 19, 2026 at 11:16 AM Alex Russell <[email protected]> > wrote: > >> LGTM1, pending test updates and such. >> >> On Thursday, October 15, 2026 at 2:56:08 PM UTC-7 [email protected] >> wrote: >> >>> 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 >>> >>> On Thursday, October 15, 2026 at 2:04:15 AM UTC-7 Philip Jägenstedt >>> wrote: >>> >>>> >>>> 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? >>>> >>>> On Wed, Oct 14, 2026 at 7:49 PM 'Fernando Fiori' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> *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 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 >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH3PR00MB2480A0093FF93B090CE7DFDADC9D2%40CH3PR00MB2480.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> 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/25748a7d-275a-450d-9a83-d3841faffa44n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25748a7d-275a-450d-9a83-d3841faffa44n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- 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/b5ba5c44-fecb-4e8a-b579-4e607e9daa46n%40chromium.org.
