← Chrome 151 reference

v151 · permissions-policy · iframes · focus

Permissions Policy: focus-without-user-activation

Chrome 151 introduces a focus-without-user-activation Permissions Policy feature that lets embedders control whether embedded iframes can programmatically move focus without a prior user activation. When denied, calls to element.focus(), autofocus, dialog.showModal(), and popover focusing are blocked unless the user has interacted first.

at a glance

Shipped inChrome 151 (Enabled by default)
StatusEnabled by default (previously Origin Trial in Chrome 149–152)
SpecWHATWG HTML §focus-without-user-activation-feature
Standards position (Firefox)Mozilla standards-positions #1080 (no signal)
Standards position (Safari)WebKit standards-positions #406 (support)
ChromeStatus5179186249465856 — Permissions Policy: focus-without-user-activation
Source: chromestatus.com/feature/5179186249465856; ChromeStatus API record; milestone 151 features

Implementation-status divergence, both sides reported rather than resolved (fetched 2026-10-07): this page records focus-without-user-activation enabled by default in Chrome 151, while the ChromeStatus API record top-level status string still reads “In developer trial (Behind a flag)” (accurate_as_of 2026-04-24) and records origin trial stage 150 running across milestones 149–152.

why it exists

Embedded third-party iframes can steal focus from the embedding page by calling element.focus() or triggering an autofocus attribute without any user interaction. This is disruptive in embed-heavy layouts (dashboards, ad slots, widget galleries) where unexpected focus shifts break keyboard navigation and screen-reader context.

The focus-without-user-activation policy gives the embedding page control: when the policy is denied for a frame, all programmatic focus calls inside that frame are silently ignored unless a user gesture has occurred first. User-initiated focus (clicking, tabbing) is never affected — the policy only blocks programmatic focus without a prior activation.

Focus delegation is still supported: a parent frame that currently has focus can transfer it programmatically to a child iframe even if the child has the policy denied.

Source: chromestatus feature summary; W3C Permissions Policy issue #273; focus-without-user-activation explainer

shape of the API and controlled operations

Per WHATWG HTML PR #10672 and MDN Permissions Policy reference, the feature can be declared via HTTP header or the iframe allow attribute:

Permissions-Policy: focus-without-user-activation=()
Policy featureDefault allowlistSet via
focus-without-user-activation* (allowed everywhere by default)Permissions-Policy HTTP header or <iframe allow> attribute

Focus calls blocked when denied: element.focus(), autofocus attribute, window.focus(), dialog.showModal(), and popover auto-focusing. Blocked programmatic focus calls fail silently without throwing exceptions, preserving backward compatibility.

Never blocked: user-initiated focus (click, tab key, touch).

Source: WHATWG HTML §focus-without-user-activation-feature; chromestatus.com/feature/5179186249465856

examples

Denying programmatic focus for untrusted subframes while allowing focus delegation:

<!-- Deny programmatic focus for an embedded iframe -->
<iframe
  src="https://widget.example.com"
  allow="focus-without-user-activation 'none'"
></iframe>

<!-- Via HTTP response header (applies to all child frames) -->
<!-- Permissions-Policy: focus-without-user-activation=() -->

<!-- Focus delegation still works: parent transfers focus to iframe -->
<iframe id="child" src="https://widget.example.com"
        allow="focus-without-user-activation 'none'"></iframe>
<script>
  // This works — parent delegates focus to child
  document.getElementById('child').focus();
  // Inside the iframe, element.focus() is then allowed within the child's subtree
</script>

browser support

BrowserSupportNotes
Chrome 151+Enabled by defaultAll platforms (origin trial in Chrome 149–152)
Edge 151+Enabled by defaultChromium mirror
FirefoxNo signalTracked in Mozilla standards-positions #1080
SafariSupportTracked in WebKit standards-positions #406
Source: chromestatus.com/feature/5179186249465856; WPT results

see also