The default bug view has changed. See this FAQ.

Enable dom.forms.selectSearch by default

NEW
Unassigned

Status

()

Core
Layout: Form Controls
2 months ago
7 days ago

People

(Reporter: mconley, Unassigned, NeedInfo)

Tracking

(Depends on: 5 bugs)

Firefox Tracking Flags

(Not tracked)

Details

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.
Depends on: 1332294, 1332280
No longer depends on: 1309935
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?
Flags: needinfo?(ryanvm)
Flags: needinfo?(jgriffiths)
Flags: needinfo?(ryanvm) → needinfo?(rares.bologa)
(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.
Flags: needinfo?(jgriffiths)
Flags: needinfo?(pdolanjski)
Mike, did UX design the current experience?  If so, who was involved?
Flags: needinfo?(pdolanjski) → needinfo?(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?
Flags: needinfo?(mconley) → needinfo?(jaws)
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).
Flags: needinfo?(jaws)
Depends on: 1309935

Updated

2 months ago
Flags: needinfo?(rares.bologa) → needinfo?(jwilliams)
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?
Flags: needinfo?(bram)

Comment 7

2 months ago
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?
Flags: needinfo?(bram) → needinfo?(mconley)
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.
Flags: needinfo?(mconley)
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.
Flags: needinfo?(bram)

Comment 10

2 months ago
(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?
Flags: needinfo?(bram) → needinfo?(jaws)

Updated

2 months ago
Depends on: 1337554

Comment 11

2 months ago
I’ve filed bug 1337554 to address issue #2 on comment 7 and comment 8.
Depends on: 1337021
Depends on: 1337023
Depends on: 1337025
Depends on: 1337034
(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.
Flags: needinfo?(jaws)
Depends on: 1343569
You need to log in before you can comment on or make changes to this bug.