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 On Wednesday, October 21, 2026 at 6:09:08 AM UTC-7 [email protected] wrote: > 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)? > On 10/21/26 7:04 a.m., Yoav Weiss (@Shopify) wrote: > > LGTM3 > > On Wednesday, October 21, 2026 at 1:18:42 AM UTC+2 [email protected] > wrote: > >> 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 <https://github.com/whatwg/html/issues/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 >> On Monday, October 19, 2026 at 6:09:17 PM UTC-7 [email protected] >> wrote: >> >>> This looks like a good feature. LGTM2 >>> On 10/19/26 7:54 p.m., 'Fernando Fiori' via blink-dev wrote: >>> >>> 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 >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5ba5c44-fecb-4e8a-b579-4e607e9daa46n%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/b24627b2-6de3-42ae-8b66-b2718094867en%40chromium.org.
