1332301 - Enable dom.forms.selectSearch by default

Status: NEW

(Core :: Layout: Form Controls, enhancement)

Description

[Mike Conley (:mconley) (:⚙️)]

Bug 1309935 introduced a feature that allows users to search <select> dropdowns when they contain 40 or more items.

That feature is preffed off behind the dom.forms.selectSearch flag.

We should coordinate with Product and QA to see if we can figure out what the requirements would be to ship this thing by default.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey canuckistani - who from Product do you think we should ask about flipping this thing on by default?

RyanVM - assuming we can get Product's blessing on doing this, do you know who we might talk to from QA about testing the feature?

Comment 2

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Mike Conley (:mconley) from comment #1)
> Hey canuckistani - who from Product do you think we should ask about
> flipping this thing on by default?

Feels like something pdol or Joe Cheng might be interested in. Sounds good to me as long as we have a robust QA plan.

Comment 3

[Peter Dolanjski [:pdol]]

Mike, did UX design the current experience?  If so, who was involved?

Comment 4

[Mike Conley (:mconley) (:⚙️)]

The spec we based this off of was posted here: https://bug1091592.bmoattachments.org/attachment.cgi?id=8776005

That spec was attached to bug 1091592 in bug 1091592 comment 18. jaws, did that spec come from phlsa like the rest of it?

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

No, I came up with the design for the search-within-select design. This is based off of https://bugzilla.mozilla.org/show_bug.cgi?id=1283772#c0, and I tried different values to see where it made sense and where it didn't. 40 felt like a good starting point, as it was large enough that visually scanning was slower, and not too large that it would never be used (see list of US states).

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Hey bram - I remember contacting you a few weeks back about looking at this feature. Does it pass muster, or are there UX bugs with it that we should address before flipping this thing on?

Comment 7

[Bram Pitoyo [:bram]]

Hi Mike. Sorry for the overdue reply. I only had the chance to review this feature late last week and yesterday.

There are a couple of polish bugs I saw:

1. When the height of the dropdown menu narrows down because of search results narrowing down, the whole menu box jumps abruptly to the top or bottom side of the screen.

https://d17oy1vhnax1f7.cloudfront.net/items/193J181D3D0D41122I0t/select-box-jumps-abruptly.gif

Furthermore, if the menu is located on top of the screen, the search box will jump down abruptly as as the list narrows down

https://d17oy1vhnax1f7.cloudfront.net/items/1k0q1N243z3i351u1i1W/search-box-jumps-down-abruptly.gif

Fix: If a search box is present, the list box should always open below. This will keep the menu on the same side of the screen, and also keep the search box on top of the menu even as the search result narrows down.


2. When you scroll down the list, the search box disappears.

Fix: the search box should always stick on top of the menu, no matter where in the list you are.

https://d17oy1vhnax1f7.cloudfront.net/items/1n3d2T2f0M1H1I0H1Q0r/search-box-always-on-top.png


3. When you open the dropdown menu and start typing, it defaults to searching inside the menu instead of searching with the search box.

Fix: Every time the dropdown menu opens, the search box should be focused by default – ready to receive keyboard input.


4. This is just a small nit. The top margin of the search box should match the side. The current value is ~8px for the top, and ~4px for the left and right sides.

Fix: make the margin the same size all around?


My recommendation would be to at least fix issue #1 and #2 before flipping this feature on. Issue #3 can come afterwards, and #4 is a nice to have that can be a bit delayed.

What do you think?

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

Thanks for the feedback Bram.

Issue #1 is covered by bug 1332280 and bug 1332294. I think your approach of having it always open at the bottom is the simplest, though in cases where there isn't enough room because the menu is at the bottom of the screen we would have to flip it. I'm not sure what we should do there. Bug 1332294 has an idea about that.

Issue #2 is also a good idea, and not covered by a bug on file yet.

Issue #3 may be a bit problematic. We didn't do this because we are worried about breaking existing user muscle memory. Typing in the search box will provide a different search than typing without having focus on the search box. For example, typing "s" in the search box would jump the user to the first option that includes an "s", whereas typing "s" outside the search box would jump the user to the first option that begins with an "s".

Issue #4 is good and would be easy to adjust.

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

Bram, what do you think we should do about issue #1? Here is an example of why we need to flip: https://www.screencast.com/t/3Z0coO5Y If you look at the screenshot, there isn't much room in this case for the popup to open below the button, but enough room if it opened above it.

Comment 10

[Bram Pitoyo [:bram]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #8)

You stated the problem with the patch on bug 1332280:

> disabling flipping means that menus opened near the edge of the screen may
> be too small to be useful.


And provided a good solution on bug 1332294:

> If the search box was placed right next to the <select>, then as the
> dropdown resizes the search box would still stay in the same place.
>
> We may also want to fix the position of the search box so that it is
> always visible and can't be scrolled out of view in the dropdown.


I like this idea. Instead of making the menu always open at the bottom of the screen, what if we instead make the search bar affixed on top if the menu opens below, and affixed on the bottom if the menu opens above?

https://d17oy1vhnax1f7.cloudfront.net/items/083X270N2B0O1E2Z231O/dropdown-menu-search-bar.png


There’s still an issue here. What if the list narrows down through search, so that the menu changes from top to bottom (or vice versa)?

If we affix the search bar, the solution to this problem is simpler: if the menu opens on top, then no matter how much it narrows down, it should always remain on top (instead of switching region based on where it gets enough space). Same goes if the menu opens on the bottom.

What do you think?

Comment 11

[Bram Pitoyo [:bram]]

I’ve filed bug 1337554 to address issue #2 on comment 7 and comment 8.

Comment 12

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Bram Pitoyo [:bram] from comment #10)
> If we affix the search bar, the solution to this problem is simpler: if the
> menu opens on top, then no matter how much it narrows down, it should always
> remain on top (instead of switching region based on where it gets enough
> space). Same goes if the menu opens on the bottom.
> 
> What do you think?

Yeah, this should work. This can be handled by the work that I had started in bug 1332280. It seems we should get bug 1332294 fixed first.

Comment 13

[Jens]

I would really like to use this feature and looking at the conversation here it seems like development on this has stalled about a year ago. Which I find very unfortunate because implementation is done it's "only" an issue of polishing and QA still.

I cannot find any reason or status here, looks a bit like being "forgotten". Since I do not know any better I am NIing canuckistani (hope that's fine) what's the plan or for forwarding the NI.

Also for transparency. As a user of "older" business applications (no fancy select2, selectize or any similar select js widget) this feature would be a USP for Firefox since it makes large selects so much nicer to handle. (I even pref'ed  dom.forms.selectSearch on now, but on focus and hitting <space> the "Search" is not focussed automatically and requiring me to use still the mouse - maybe also a minor polishing issue).

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Hi Jens,

I suspect part of the reason for the delay is that there have been unacceptable performance penalties with rendering the <select> dropdown the way we do. That's had greater priority, and has resulted in bug 1421229, where kuoe0 is working on making the rendering far more performant. After that, we might have the cycles to reintroduce this feature.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Bug 1421229 is wontfix now... Is this blocked on something else?

Comment 16

[Mike Conley (:mconley) (:⚙️)]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #15)

Bug 1421229 is wontfix now... Is this blocked on something else?

I think it's blocked mainly on UX / Product sign-off and some rigorous testing. Otherwise, I think it's feature complete.

Comment 17

[Amelia Bellamy-Royds]

Some relevant discussion on the standardization side, about whether filterable select boxes should be something the web author controls:
https://github.com/WICG/open-ui/issues/104

While testing the Firefox implementation for that discussion, I found some keyboard accessibility issues. Specifically, I can't seem to focus the search box via keyboard. Typing while the select has focus (with or without the dropdown expanded) just triggers the old type-ahead behavior. Spacebar expands/closes the dropdown but doesn't focus the search. Tabbing closes the select / moves focus to the next input. Arrow buttons cycle through the current list but do not focus the search.

Another usability issue: if the currently selected option is scrolled down the list, the search box isn't visible when the dropdown is expanded. It shouldn't be part of the scroller, or else it should be sticky within it.

Comment 18

[Shane Hughes [:aminomancer]]

any news on the search box getting scrolled with the list? i guess it's splitting hairs but it feels more like a defect than an enhancement request to me. i get this is all locked behind a pref in the first place but the enhancement already exists. the only problem is that the interactive component of that feature is just defective.