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/4f2858d2-41c7-40a7-8c33-ce8f2b7960een%40chromium.org.
