@@ -11,13 +11,13 @@ Automatic focus could happen through:
1111* Use of scripted focus such as `element.focus()` and `window.focus()`.
12121313Automatic focus is potentially
14-[problematic](https://github.com/w3c/webappsec-feature-policy/issues/273) since it provides bad
14+[problematic](https://github.com/w3c/webappsec-permissions-policy/issues/273) since it provides bad
1515embedded content with a tool to steal input focus from the top-level. The proposed feature provides
1616a means for developers to block the use of automatic focus in nested contents.
17171818Proposed Solution
1919------------
20-The proposed feature policy can be used to limit the use of automatic focus. Essentially, when the
20+The proposed permissions policy can be used to limit the use of automatic focus. Essentially, when the
2121policy is disabled in a document, scripted and automatic focus will only work if the focus has been
2222initialized through user activation. This essentially means that `autofocus` will be disabled
2323(unless a new element is inserted, with `autofocus`, as a result of user gesture). The scripted
@@ -32,13 +32,13 @@ In a nutshell:
3232* Around step 4 of the [spec](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-autofocus) for `autofocus` the algorithm should return if the policy `focus-without-user-activation` is disabled and the algorithm is not
3333[triggered by user activation](https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation).
3434* Before starting [steps](https://html.spec.whatwg.org/multipage/interaction.html#dom-window-focus) for `element.focus(options)` the same verification for the policy and user activation should be performed.
35-* Around step 2 of the the [spec](https://html.spec.whatwg.org/multipage/interaction.html#dom-window-focus) for `window.focus()` the same enforcement should be made (using the browsing context of the `window` itself to obtain the feature policy state.
35+* Around step 2 of the [spec](https://html.spec.whatwg.org/multipage/interaction.html#dom-window-focus) for `window.focus()`, the same enforcement should be made (using the browsing context of the `window` itself to obtain the permissions policy state).
36363737Using the Feature
3838-------------
3939This feature can be introduced with the HTTP headers. For instance,
4040```HTTP
41-Feature-Policy: focus-without-user-activation 'none'
41+Permissions-Policy: focus-without-user-activation=()
4242```
4343would cause the use of automatic focus in the page (and nested contexts) to fail unless it
4444has been triggered by user activation.
@@ -54,3 +54,34 @@ The Extra Mile
5454-----------
5555Automatic focus, in general, poses security concerns. It might be a good idea to disable this policy
5656in all sandbox-ed frames (treat the policy as a sandbox flag).
57+58+Alternative Solutions Considered
59+-----------
60+This section lists other possible solutions that were considered during the development of the proposal outlined in this explainer.
61+62+1. **HTMLIFrameElement boolean attribute**: A new `disallowprogrammaticfocus` boolean attribute on the [HTMLIFrameElement](https://html.spec.whatwg.org/multipage/iframe-embed-object.html#htmliframeelement) was explored. When set, this attribute would prevent all nested iframes from taking input focus through script. An example implementation would look as follows:
63+64+```html
65+ <!DOCTYPE html>
66+ <html>
67+ <head>
68+ <meta charset="utf-8">
69+ <title>iframe steal focus prevention</title>
70+ </head>
71+ <body>
72+ <iframe src=""
73+disallowprogrammaticfocus>
74+ </iframe>
75+ </body>
76+ </html>
77+```
78+79+ In this approach, the iframe would be unable to steal focus unless the user explicitly switches focus to that element.
80+81+ This approach was abandoned because it represents a heavier-weight solution compared to a permissions policy. Additionally, it would be easier for sites to adopt a new permissions policy if they are already using permissions policies to control other behaviors, rather than introducing a new HTML attribute.
82+83+2. **Alternative policy naming**: An alternative policy name was considered: `disallow-programmatic-focus`. However, to maintain consistency with existing permissions policies, it is more appropriate to use positive polarity (where denying the policy disables the functionality) for backwards compatibility.
84+85+3. **Sandbox flag approach**: The possibility of implementing this control as a [sandbox](https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/sandbox) flag was analyzed instead of a permissions policy.
86+87+ Adding this functionality to the sandbox would be potentially breaking, as it would immediately affect every sandboxed frame and require all sites to update their code if they needed to restore the functionality. In contrast, implementing this as a permissions policy is non-breaking: with a default allowlist of `'self'`, it provides an opt-in control mechanism that is enabled by default everywhere but can be selectively disabled when needed.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。