Skip to content
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

Open
josepharhar opened this issue Jan 24, 2024 · 5 comments · May be fixed by #10098 or #10344
Open

Should showPicker() consume user activation? #10084

josepharhar opened this issue Jan 24, 2024 · 5 comments · May be fixed by #10098 or #10344
Labels
agenda+ To be discussed at a triage meeting security/privacy There are security or privacy implications security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. topic: forms

Comments

@josepharhar
Copy link
Contributor

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

@lukewarlow
Copy link
Member

Does the same issue apply to inputs? The idea with the spec is to match inputs existing behaviour.

@josepharhar
Copy link
Contributor Author

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?

@lukewarlow
Copy link
Member

Other than back compat I can't think of a reason not to

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 24, 2024
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
@annevk annevk added security/privacy There are security or privacy implications topic: forms security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. labels Jan 25, 2024
josepharhar added a commit to josepharhar/html that referenced this issue Jan 26, 2024
@josepharhar josepharhar linked a pull request Jan 26, 2024 that will close this issue
5 tasks
@josepharhar
Copy link
Contributor Author

I created a PR: #10098

@evilpie
Copy link

evilpie commented Jan 29, 2024

Barring any new feedback, I think Mozilla is supportive of this change. In fact we were already implicitly consuming the user activation for <input type=color> and <input type=file> in Firefox.

CanadaHonk added a commit to CanadaHonk/html that referenced this issue May 13, 2024
More in-depth alternative to whatwg#10098. Fixes whatwg#10084, helps GHSA-hr74-5fj7-jgxp.
@CanadaHonk CanadaHonk linked a pull request May 13, 2024 that will close this issue
5 tasks
@zcorpan zcorpan added the agenda+ To be discussed at a triage meeting label May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda+ To be discussed at a triage meeting security/privacy There are security or privacy implications security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. topic: forms
6 participants
@zcorpan @evilpie @annevk @josepharhar @lukewarlow and others