Create focus-without-user-activation.md #304
Conversation
Add an explainer for `focus-without-user-activation` policy which helps reduce abusing automatic focus in embedded contents.
| ```HTTP | ||
| Feature-Policy: focus-without-user-activation 'none' | ||
| ``` | ||
| would cause all all automatic focus in the page (and neste contexts) to fail unless it has been |
There was a problem hiding this comment.
Redundant "all", "neste" -> "nested".
|
|
||
| To disable the feature for a specific `<iframe>`, the `allow` attribute can be used: | ||
| ```HTTP | ||
| Feature-Policy: focus-without-user-activation 'self' |
There was a problem hiding this comment.
Was there an intention to provide an example with <iframe allow="..">? Maybe it got lost when copy/pasting.
There was a problem hiding this comment.
Added an example.
| To avoid unnecessary breakage of existing contents, disabling the focus should still let parts of | ||
| the [focus update steps](https://html.spec.whatwg.org/multipage/interaction.html#focus-update-steps) | ||
| run. In a nutshell: | ||
| * The `activeElement` of the blocked document should be updated. All the focus related events |
There was a problem hiding this comment.
I'm not en expert on focus behavior in browsers, but does that mean that activeElement would be updated even though it actually would not be active?
There was a problem hiding this comment.
This might be a bit hand-wavy and I still need to dig through the steps in the spec, but what I am suggesting is that the document inside the <iframe> that is blocked shouldn't know about the focus not really working. I wonder if it makes sense for all the steps in focus work (inside the <iframe>) but not make it target for keyboard input (focusable area).
There was a problem hiding this comment.
I'm not sure what would be the best approach. But out of curiosity: Would you want the document not to know about focus being blocked for security reasons? Anyway, PR looks good to me.
Added an example for allow.
Make focus blocking explicit in the steps of `autofocus`, `window.focus()` and `element.focus()`.
| * 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 | ||
| [triggered by user activation](https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation). | ||
| * 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. | ||
| * Aroudn 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 obtaint he feature policy state. |
There was a problem hiding this comment.
Aroundn -> Around, obtaint he -> obtain the, closing parentheses at the end.
There was a problem hiding this comment.
Thanks you! I fixed those two and also updated the focus algorithm link (update focus steps -> focusing steps).
Fixed some typos and updated the link to focus algorithm in the spec.
|
Can't wait to see this flag usable everywhere :) |
Add an explainer for
focus-without-user-activationpolicy which helps reduce abusing automatic focus in embedded contents.