-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Should showPicker() consume user activation? #10084
Comments
Does the same issue apply to inputs? The idea with the spec is to match inputs existing behaviour. |
The security bug was about the fact that the select's popup contains author provided content which can influence the user, so I guess that input.showPicker() might not need to consume user activation while we do consume user activation for the select.showPicker() - any reason not to consume user activation for inputs too? |
Other than back compat I can't think of a reason not to |
Allowing the page to call showPicker() as much as it wants without consuming user activation may result in the user being unable to interact with the browser UI due to popups always taking focus. Spec issue: whatwg/html#10084 Bug: 1521345 Change-Id: If6308a67bac9050f695d18d275ea86c23ac22b0d
I created a PR: #10098 |
Barring any new feedback, I think Mozilla is supportive of this change. In fact we were already implicitly consuming the user activation for |
More in-depth alternative to whatwg#10098. Fixes whatwg#10084, helps GHSA-hr74-5fj7-jgxp.
More in-depth alternative to #10098. Tests: web-platform-tests/wpt#46502. Fixes #10084.
What is the issue with the HTML Standard?
https://html.spec.whatwg.org/multipage/input.html#dom-select-showpicker
These steps check for user activation but don't consume it, which allows the page to spam popups from the select element for example and prevent the user from clicking on other content or browser tabs. I got a security bug about this in chrome.
Can we add a step to consume the user activation after checking for it to prevent this abuse? Or would that break something?
@lukewarlow
The text was updated successfully, but these errors were encountered: