1882075 - Datalist doesn't indicate itself, and requires two clicks to show dropdown

Status: NEW

(Toolkit :: UI Widgets, enhancement)

Description

[Blair Noctis]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:124.0) Gecko/20100101 Firefox/124.0

Steps to reproduce:

Trying out the "ice cream flavor" example on https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist

Actual results:

1. Hovering on the input showed no sign of datalist present
2. First click focused the input, still no sign
3. Second click showed the dropdown
4. Without 3, start typing, only when input matches one of options does the dropdown show up

Expected results:

1. Hovering should show indicator of available dropdown
2. Clicking should immediately show dropdown

Chrome did both:

1. On hover, a downward triangle is shown on the far end of input field
2. On click, dropdown is shown

Probably related to https://bugzilla.mozilla.org/show_bug.cgi?id=55274 and https://bugzilla.mozilla.org/show_bug.cgi?id=595457

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jonathan Kew [:jfkthame]]

I don't think there's any clear specification for exactly how this should behave, and there's considerable variation among existing browsers. I notice that in Safari, an arrow indicator is always shown, even without hovering or clicking the input field.

The potential downside of "eagerly" showing the arrow (either all the time, as in Safari, or on hover, as in Chrome), IMO, is that it might mislead the user into thinking that they can only choose from the suggestions in the list, rather than having the freedom to enter a new value. In the Firefox model, it may be clearer to the user that they're interacting with an editable field rather than only a dropdown menu.

This may be better directed to the Toolkit: UI Widgets component, for consideration of what the UX/interaction here should be.

Comment 3

[Blair Noctis]

… it might mislead the user into thinking that they can only choose from the suggestions in the list, rather than having the freedom to enter a new value.

IMO a blinking input cursor and cursor: text; can't be mistaken.

If that's ignored, you can, for example, add placeholder="Select one or type…".

If that's ignored, maybe Select one: <select>…</select> or type: <input>.

See an example at https://codepen.io/pen/qBwdQpr.

Besides, macOS is quite clever, also IMO, in that a <select> dropdown covers the base element.

Comment 4

[Mark Striemer [:mstriemer]]

Hey, looks like other browsers provide more of an indication that there are options to select from here. Do you have an opinion on what this UX should look like or who would have that opinion?

Comment 5

[Jules Simplicio [:jules]]

Hey all, happy to share my opinion from the UX perspective.

Overall, I agree that we should try to avoid making this look too much like a <select> so that folks can have the text input affordance.

I also do feel similar to Blair that the text cursor on hover and the blinking cursor on click is a pretty good affordance that this is a text input. So perhaps we go for the approach similar to Chrome and Edge of also showing a dropdown arrow ( ▾ ) on hover as the affordance for the additional dropdown behavior. I see those browsers also have the default cursor if you hover over the arrow itself, so that can also be a nice touch. I also agree we should automatically display the dropdown list on click.

I can't think of a better solution for somewhat combining the behaviors of a text and a dropdown type input, but I feel if we provide enough affordance, I am hopeful users will recognize the familiar behaviors. Happy to also share this with the broader UX team to hear other opinions.

Comment 6

[buovjaga]

Sergey: adding you to Cc as this (two left clicks required) is the issue I discussed with you via private emails last year.

Bug 665728 is a request that would allow for a JS workaround for this issue. It has a simple test case as attachment 9351265 [details].

I am copying here the relevant content from my first email, note especially the test cases relying on the current behaviour:

I have grepped through the source code and commit history and debugged the code, but the location of the relevant code eludes me. For example, I recorded a session of clicking an input with a datalist and hitting down arrow with

./mach run --temp-profile --debugger=rr

Then I replayed it with rr replay and set a conditional breakpoint to sniff for down arrow events with

b gfx/layers/apz/src/KeyboardMap.cpp:150 if aEvent.mKeyCode==40

I dumped all of the steps to a file with

set pagination off
set logging enabled on
while 1
  step
end

Searching in the dump I could not find anything interesting.

Most recently I noticed I can definitely change the event handling by messing around with the switch cases in
https://hg.mozilla.org/mozilla-central/file/6462df7bf9184c6c728d00d99df71f72682618bc/toolkit/components/satchel/nsFormFillController.cpp#l873

Ie. building a change like

case eKeyDown:
  return Focus(aEvent);

makes down arrow stop working as normal in the input element. However, if I set a breakpoint in rr for the switch block, it is never reached.

I have also noted down the automated tests that should be adjusted in case the behaviour change is accepted:
mozilla-unified/accessible/tests/mochitest/events/test_focus_autocomplete.html
browser/components/extensions/test/browser/browser_ext_autocompletepopup.js

Sergey noted this in a reply to me:

"It looks like we intentionally prevent showing both the context menu and the autocomplete popup after right click"

Comment 7

[dmalmald]

I've found the Chromium way of indicating the possibility to choose from a list decent. The arrow shows up on hover, or when you tab into the field.
On input type=date and input type=time, Chromium does not show an arrow, which is inconsistent. But if you click the calendar or clock symbol, the options from the list show up with a new item added to the end that says "Other..." (or similar). When you select that, the usual date / time picking interface will show up.

I think something like this could also work on the other input types. In case of text or url, choosing "Other..." could just empty the input field and let you start typing.

Comment 8

[dmalmald]

related issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1905313