concept · Privacy & Security

Autofocus Lockdown

The HTML autofocus attribute lets a form control grab keyboard focus the moment a document loads — before the user has touched the page. In an embedded iframe this becomes a focus-hijacking vector. The policy blocks it.

Unrestricted iframe autofocus ACTIVE
<iframe src="frame.html">
Policy-restricted iframe autofocus BLOCKED
<iframe src="frame.html" allow="focus-without-user-activation 'none'">
Both frames load frame.html which has <input autofocus> and checks document.activeElement after load. The left frame shows a green badge — autofocus fired. The right frame shows red — the policy silently suppressed it. The input is still focusable by clicking or tabbing; only the automatic initial focus is blocked.

markup

<!-- Inside frame.html --> <input autofocus type="text" placeholder="This has autofocus"> <!-- Unrestricted embed: autofocus fires as normal --> <iframe src="frame.html"></iframe> <!-- Restricted embed: autofocus is blocked --> <iframe src="frame.html" allow="focus-without-user-activation 'none'"> </iframe>

real-world use cases

embedded payment widgets

A payment form embedded in a checkout page should not steal focus away from the main page's fields the moment it loads. The embedding site restricts the widget without touching the widget's code.

ads and analytics iframes

Third-party ad iframes sometimes misuse autofocus to capture keyboard events. The policy blocks this at the browser level, regardless of what the third-party script does.

collaborative document editors

An editor that embeds plugin panels in iframes can ensure that only the main editing area holds focus on load, keeping keyboard shortcuts consistent.

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗