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.
