Consume user activation in show the picker

[CanadaHonk]

More in-depth alternative to #10098. Fixes #10084, helps GHSA-hr74-5fj7-jgxp. cc @zcorpan @lukewarlow @josepharhar @domenic @annevk

• At least two implementers are interested (and none opposed):
  • Gecko
  • Chromium
• Tests are written and can be reviewed and commented upon at:
  • Consume user activation in show the picker web-platform-tests/wpt#46502
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/343093082
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1877969 (private)
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=274779
• MDN issue is filed: Spec PR: Showing pickers to consume user activation mdn/content#33795
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/input.html ( diff )

[josepharhar]

This seems to accurately describe what I implemented in chromium here, so I am supportive: https://chromium-review.googlesource.com/c/chromium/src/+/5235516

[lukewarlow]

@josepharhar one key difference is that this applies to the main algorithm not just the showPicker() function. So there's a difference here from your patch.

[josepharhar]

Ah ok, I can see that calling element.click() on <input type=color> currently opens the picker, so if we made it check for and consume user activation, that could be a breaking change. Calling element.click() on <select> doesn't seem to currently do anything though.

I think it would probably be a good idea to make that require user activation though since it opens a popup document. I can guard the change behind a flag and revert it if websites are relying too much on it or something.

Let's do it!

The WPT should probably test the element.click() cases, right? This algorithm does get called when doing element.click(), right?

[CanadaHonk]

The WPT should probably test the element.click() cases, right? This algorithm does get called when doing element.click(), right?

Yes and yes

[lukewarlow]

My only concern with this is, stylable select will be a popover so does it really need to be concerned with user activation? Is it possible we should scope this to just pickers that can escape the bounds (current select and file?). Either way I think that's a concern we can address in future, just wanted to point it out.

[josepharhar]

My only concern with this is, stylable select will be a popover so does it really need to be concerned with user activation?

No it shouldn't, and you can just call showPopover() on the datalist element. However, stylable select doesn't exist in the spec yet (hopefully it will someday), and if that really is an issue, then we can patch the algorithm to check whether it's in appearance:base-select mode or not.

Is it possible we should scope this to just pickers that can escape the bounds (current select and file?)

<input type=color> escapes the window bounds on chrome on linux.

My only concern is still that we would break existing websites, so I would launch the change behind a flag and disable+revert it if we get a lot of feedback about it.

[evilpie]

For consistency and safety we should apply this to everything. For example in Firefox the <input type=date> date picker can also extend outside the browser window.

[CanadaHonk]

WPT PR: web-platform-tests/wpt#46502

[annevk]

No it shouldn't, and you can just call showPopover() on the datalist element.

What if there's no datalist element? I suspect this needs some more work. In particular as forcing style resolution also doesn't seem ideal. But that all can indeed be done at a later stage.

[annevk]

I suspect we probably want this documented on MDN in due course so please file an issue. Also seems good to file bugs against Chromium and WebKit for this.

[CanadaHonk]

Filed bugs for vendors and MDN. Are there any other blockers for this merging at the moment?

[annevk]

Thanks @CanadaHonk for fixing this!