select: use cases for opening the picker without user activation

[josepharhar]

In this HTML issue we are trying to make the customizable select popover showable without user activation, which we currently need for WPTs. However, without non-testing use cases we will likely have a hard time making progress in this area.

Can anyone think of reasons they'd want to show the picker without user activation?

[mfreed7]

@westbrook I would assume there might be custom element needs for calling showPicker() on <select> without user activation, but I'm not sure what they would be. Can you offer any input here?

[Westbrook]

Not specific to custom elements as much as UX in general... I could see wanting something like this for a "new document" page, where in the <select> for type was open by default and then you could change the type from the same form control before completing the document settings.

Play out the above as a custom elements and JS... an interaction writes <new-document> to the page with the dynamic import of its definition. The definition loads later (for reasons) but once upgraded, <new-document> would like the <select> for type open by default. Would the user interaction span all the way through to the upgrade step?

The larger context of "autofocusing" a decision that can be edited before submitting feels like something the move to a style-able <select> specifically unlocks?

I've passed the request for use cases onto the WCCG, we'll see what others in this area might be looking for here.

[sorvell]

My initial reaction is this feels wrong. Select is basically like a menu, and I don't really want code to be able to open a menu for me. Seems like it makes it too easy to get/prompt bad user input.

[css-meeting-bot]

The Open UI Community Group just discussed select: use cases for opening the picker without user activation, and agreed to the following:

• RESOLVED: There are real world usecases for opening a picker using programmatic activation on a custom select

The full IRC log of that discussion

<gregwhitworth> masonf: the question is a link to the WHATWG question
<gregwhitworth> masonf: there is this thing called showPicker() that works for select, etc
<gregwhitworth> masonf: in all of those scenarios they open a separate window and they REQUIRE user activation since it's in a new window. In customizable select it is not a new window and so it is not a privelaged window
<gregwhitworth> masonf: should it be allowed to be triggered without user activation
<gregwhitworth> masonf: there aren't any real concerns from a security perspective but is there a usecase for this? The only clear one is that it's for testing
<brecht_dr> q+
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: I'm feeling strongly towards needing it rather than an opinion on this with something like invokers
<gregwhitworth> q+
<gregwhitworth> brecht_dr: you could open it?
<gregwhitworth> masonf: what do we do with invokers, we do click which are user activation
<gregwhitworth> masonf: I don't think it works right now if you have an invoker and point it to select and programatically have it invoke the click
<gregwhitworth> masonf: targeting a select is a new capability for an invoker
<gregwhitworth> brecht_dr: I wanted to ask the question alongside it. Could this impact that behavior in some way. I'm not opposed to having not having this but I do like the idea of invokers and using it for select
<gregwhitworth> masonf: I see, I don't see why the commandfor shouldn't be able to point to a select and that open the select
<masonf> q?
<gregwhitworth> masonf: and that is the user activation
<gregwhitworth> ack masonf
<gregwhitworth> ack gregwhitworth
<gregwhitworth> masonf: I don't think we NEED a resolution for this
<jarhar> gregwhitworth: so this is a noop api now?
<jarhar> masonf: if you call showpicker with no activation, it throws an exception right now.
<jarhar> gregwhitworth: i like having the artifact that we are resolving to keep the behavior as is
<jarhar> gregwhitworth: but we intentionally made the decision not to change the behavior
<jarhar> masonf: i was hoping for the opposite resolution
<jarhar> gregwhitworth: im not opposed to it either, but i dont see a strong reason to change the html spec
<sarah> q+
<jarhar> gregwhitworth: the irony is the scenarios that popped into my head: the dropdown is opened by default, but that is occurring due to focus being forced into that thing
<jarhar> masonf: that was something from westbrook, which was having it open by default on page load. that would not be possible without this
<jarhar> gregwhitworth: i can't recall. when we focus in on the select does it happen or is it with the keyboard?
<jarhar> masonf: keyboard
<jarhar> gregwhitworth: ok yeah. there are use cases where it forces you into a pick list by default
<brecht_dr> q+
<jarhar> gregwhitworth: so when this thing gets focused i would show that popup
<jarhar> gregwhitworth: i cant remember where i encountered this in salesforce
<jarhar> gregwhitworth: when we were talking about open forever, people were saying we want defaultopen, but people can programatically do it
<jarhar> masonf: defaultopen was a declarative way to do something you can do with script. but this is different because you can't do it in script at all
<jarhar> gregwhitworth: this would become a web compat concern since its throwing exceptions
<gregwhitworth> ack sarah
<gregwhitworth> sarah: the caveat is that the usecases are on editable comboboxes with open on focus
<gregwhitworth> sarah: there are things where we want to keep them open all the time while you're typing
<brecht_dr> q-
<gregwhitworth> sarah: the other is when you have teaching UI and you have a thing that we open programmatically
<dbaron> +1 to the teaching UI case (which I was thinking about mentioning)
<sarah> ack me
<gregwhitworth> masonf: I have two examples from this discussion which is opening on load and teaching UI where it opens the select
<gregwhitworth> Proposed Resolution: There are real world usecases for opening a picker using require programmatic activation on a custom select
<masonf> +1
<gregwhitworth> Proposed Resolution: There are real world usecases for opening a picker using programmatic activation on a custom select
<brecht_dr> +1
<gregwhitworth> RESOLVED: There are real world usecases for opening a picker using programmatic activation on a custom select
<sarah> +1

[mfreed7]

So we discussed this and two real world use cases were raised:

• Opening the select picker on page load, to help the user get started with an action/choice.
• "Teaching UI" that roams around the screen showing users how to use things, and wants to open select pickers to "teach" what options are available.

[scottaohara]

if a select was opened by default, wouldn't it need to be focused by default? Since any focus event outside of it should close it (we had this same discussion about auto popovers in general).

but if that would be special cased to handle not being focused by default / allow for focus to move around the document w/out auto-closing the popup, then... eh?