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/9544a5c1-b0de-40bf-b030-63ff0666458dn%40chromium.org.

Reply via email to