Add showPicker to <select> elements

[lukewarlow]

Closes #7957 and #9757

Mini-explainer for TAG review / blink-dev purposes:

The showPicker() method is a new addition to HTMLSelectElement which addresses a common request from web developers: programmatically showing the option picker UI for a select element

<select id="select">
  <option>Item 1</option>
  <option>Item 2</option>
</select>
<button onclick="select.showPicker()">Show the select option picker</button>

In today's browsers there's currently no way to programatically open a select element. This spec adds a new method to a select element to make that possible, following in the footsteps of the showPicker() method added to HTMLInputElement.

showPicker() is specified with a few restrictions to improve security:

It can only be called with transient user activation. If called without, it will throw a "NotAllowedError" DOMException. (This is the same as how it behaves on inputs.)

It can only be called in same-origin iframes. If called in a cross-origin iframe, it will throw a "SecurityError" DOMException.

• At least two implementers are interested (and none opposed):

  • Gecko
  • Chromium (Add showPicker to <select> elements #9754 (comment))

• Tests are written and can be reviewed and commented upon at:

  • Add showPicker() method to HTMLSelectElement interface web-platform-tests/wpt#42091 - tests user gesture, mutability and same-origin requirements.
  • Actually showing the picker is not testable in WPT

• Implementation bugs are filed:

  • Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1485010
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1854112
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=261814

• MDN issue is filed:

  • Add data for HTMLSelectElement showPicker mdn/browser-compat-data#20852 MDN Browser Compat Data PR
  • Add page for HTMLSelectElement showPicker() mdn/content#29406 MDN Content PR

• Standards Positions:

  • Gecko: HTMLSelectElement showPicker() mozilla/standards-positions#886
  • WebKit: HTMLSelectElement showPicker() WebKit/standards-positions#258
  • Chromium: https://chromestatus.com/feature/5111537299881984

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

---

/acknowledgements.html ( diff )
/form-elements.html ( diff )
/input.html ( diff )

[lukewarlow]

I'm happy to implement this in Chromium as an external contributor. Idk if that counts me as 1 implementor for the purposes of the WhatWG?

Once it's deemed this PR is wanted I'll happily go and file the necessary bugs and write any web platform tests needed.

[sideshowbarker]

s/showPicker() element/showPicker() method/

…in the first sentence of the issue description

[annevk]

If Chromium is willing to ship it enabled by default that would count as implementer interest.

[annevk]

In principle WebKit is supportive of this change, but we'd like some clarity on #9757.

[lukewarlow]

@emilio do you or any other gecko folks have any thoughts on this?

[emilio]

At a glance it seems fine. CC @evilpie who implemented showPicker(). Can you file a mozilla standards position issue? That's the way of getting a more official position :)

[lukewarlow]

Have made draft MDN PRs for this feature. All that's left is a resolution to #9757 for WebKit and I think this should be good to go?

[lukewarlow]

Anything else I can do to nudge this across the finish line?

[lukewarlow]

https://groups.google.com/a/mozilla.org/g/dev-platform/c/S9cdPUJSyL8/m/c8FUILXXAwAJ - Firefox Intent to Ship (unflagged on main)
https://groups.google.com/a/chromium.org/g/blink-dev/c/qew_ILTXWSY/m/AxHrcWzuAQAJ - Chrome Intent to Ship (flagged on main waiting for this PR to merge before unflagging)
WebKit has a partial (desktop only) implementation (flagged), needs iOS work which I plan to do and then it should be ready to go through the launch steps.

cc @annevk @domenic to give this a nudge

[annevk]

Hey @lukewarlow, I'm sorry, but I'm still a little stuck on #9757 (comment). I realize this is not adding anything new compared to what's already out there, but it seems problematic to me that the existing API is so wildly different across implementations for the disconnected case (when the element is not in the document tree). And also, that for the disconnected case which is reportedly a key use case there's essentially no way to position the widget. That seems like a rather big design flaw to me with the original feature that needs addressing first.

[lukewarlow]

I'm not actually convinced that (out of dom input) would be the majority use case? Given it basically doesn't work, and I can't think how it would without representing the pickers with pseudo elements that can take positioning data and using web tech (which wouldn't be desirable for WebKit I imagine?). That also would go counter to not wishing to expose whether a picker is implemented.

Not really sure what the next steps here are?

[lukewarlow]

If authors want the pickers without the input UI that suggests to me that this is entirely the wrong path to go down and we really should be asking OpenUI to investigate exposing the pickers themselves as usable (stylable) elements?

Again not sure what WebKit would think of that as they are keen on native looking elements?

Have opened openui/open-ui#922 to start this discussion to see if open ui are interested etc

[lukewarlow]

#9912 - uses the algorithm defined in here so I've copied this change across removing the IDL additions. This will need rebasing if that gets merged first.

[zcorpan]

I think it makes sense to require that the select element be rendered for showPicker() to work. It can be extended later if we figure out how it should work in different browsers and devices.

[lukewarlow]

@zcorpan do you envisage any wording changes to the spec?

[zcorpan]

In the showPicker() steps, just before calling "Show the picker, if applicable":

If this is a select element or an input element whose type attribute is not in the File Upload state, and this is not being rendered, then throw a "NotSupportedError" DOMException.

[lukewarlow]

Chromium currently supports showing picker for more than the file type (when not rendered). Should I just do the if this is select bit and ignore input entirely for now?

[lukewarlow]

I've added that line but only with reference to select due to the comment above. @annevk would that be enough to alleviate concerns? If not is there anything else I can do to help move things forwards :)

[annevk]

That seems reasonable to me. @domenic thoughts?

[zcorpan]

OK. It seems the picker is rendered in the top-left corner for hidden non-file input types in chromium.

I suggested NotSupportedError, but maybe NotAllowedError is also appropriate.

[lukewarlow]

I suggested NotSupportedError, but maybe NotAllowedError is also appropriate.

Apologies I missed that. Will fix that now.

[domenic]

@domenic thoughts?

I continue to think that a major use case for these will be showing the mobile full-screen pickers, which don't need a visible element to anchor to. I think that's how showPicker() is often used today on, e.g., date pickers.

However, I recognize that we haven't done good work on that front. We've made it too easy to create a good experience on mobile (e.g. a full-screen date picker) and a bad experience on desktop (e.g. no date picker in Firefox/Safari, or a date picker anchored to the top-left of the screen in Chrome).

So, taking a different route for select, where it just isn't possible to create a good experience on either mobile or desktop, seems like a reasonable first step. I hope we can do some work to allow all controls to work well on all platforms at some point though.

[domenic]

I think the syntax we've been using here, when we need to disambiguate between different base classes, is "The HTMLInputElement showPicker() method steps and the HTMLSelectElement showPicker() method steps".

[lukewarlow]

Hopefully this is addressed properly let me know if I've misunderstood.

[annevk]

(Note that on iOS a select box dropdown is not fullscreen either. It used to be displayed in the keyboard area, but these days it is inline similar to desktop. So you would need some kind of coordinate system for some mobile platforms as well.)

[lukewarlow]

Is this likely to be merged before the 17th? Just so I can update the chrome I2S accordingly.

[annevk]

@domenic final thoughts?

[annevk]

Thanks @lukewarlow for adding this feature to HTML!