Skip to content

'focus-without-user-activation' permissions policy #1066

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 task done
siliu1 opened this issue Mar 7, 2025 · 1 comment
Open
1 task done

'focus-without-user-activation' permissions policy #1066

siliu1 opened this issue Mar 7, 2025 · 1 comment

Comments

@siliu1
Copy link

siliu1 commented Mar 7, 2025

こんにちは TAG-さん!

I'm requesting a TAG review of a new permissions policy named 'focus-without-user-activation'.

The focus-without-user-activation permissions policy help controls the use of automated focus in a main frame or <iframe>. The proposed permissions policy can be used to limit the use of automatic focus. Essentially, when the policy is disabled in a document, scripted and automatic focus will only work if the focus has been initialized through user activation. This essentially means that autofocus will be disabled (unless a new element is inserted, with autofocus, as a result of user gesture). The scripted focus will also only work if it has started with user gesture or initiated from current frame's parent.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
  • Relevant time constraints or deadlines:
  • The group where the work on this specification is currently being done:
  • The group where standardization of this work is intended to be done (if different from the current group):
  • Major unresolved issues with or opposition to this specification:
  • This work is being funded by:
@matatk
Copy link

matatk commented Apr 30, 2025

Hi @siliu1, and thanks for your review request.

We are supportive of this use case, and your proposed approach seems reasonable.

However, it would be really helpful for reviewers if you could include the alternatives that were considered in the explainer, and briefly describe why they were rejected.

We are aware of a few alternative approaches that had been explored (thanks @dandclark for highlighting these):

Please could you add these - and the reasons for rejecting them - to the explainer?

Thanks again to @dandclark for assisting with this review.

@matatk matatk added the Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review label Apr 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants