Improve SelectNext arrow key navigation

[acelaya]

Part of #1285
Depends on #1288

This PR's primary focus is to improve arrow key navigation, making sure the active option is the focused one when the listbox is opened, falling back to the first option if none is active.

Additionally, we add explicit displayNames for SelectNext and SelectOption, which don't have the expected value by default due to the Object.assign(...) approach to expose the main component and its sub-components.

Testing steps

1. Check out this branch and start dev server (make dev)
2. Go to http://localhost:4001/input-select-next
3. Focus one of the selects, and press ArrowDown. Notice the list is open and the first option is focused.
4. Select some other option. The list should close.
5. Repeat step 3. The active option should be the one selected this time.

In main, the first option is the one selected when the list is open, no matter if there's an active option or not.

[robertknight]

Hmm, I'm seeing some odd behavior in Safari when testing in http://localhost:4001/input-select-next:

1. Click drop-down menu for the first select control in the page
2. Press the down arrow key, nothing is highlighted
3. Press it several more times. Eventually the bottom-most item ("Doris ...") is highlighted. None of the items before that are highlighted.

If you press Enter to select an item, the control behaves as if the expected item had been focused given the number of arrow presses, so it looks like this might be an issue with the focus ring.

If you interact with the control exclusively using the keyboard, it works as expected.

In Chrome and Firefox, it works fine with both methods of interaction.

[robertknight]

I did find an issue with the focus highlight when mixing mouse and keyboard input in Safari, and I did note an issue when mixing mouse and keyboard input in all browsers. Nevertheless this is an improvement over the previous behavior for the common case of using exclusively mouse or exclusively keyboard input.

[robertknight]

Is this because getNavigableElements returns HTMLElement[]?

[acelaya]

In essence yes, but I could not find a reason for the ref to be typed as HTMLOrSVGElement.

I'm ok doing an inline as HTMLElement cast though. We are already doing it in a couple of other places for this hook.

[robertknight]

To recap: Every time this effect ran, it reset the selected item to the first one in the list. Now it will reset it to lastFocusedItem.current. This is an improvement over the way it worked before, although lastFocusedItem doesn't currently get updated if you focus an item a different way, eg using the mouse. In the context of SelectNext, this means that if you:

1. Open the list and select an item using the keyboard
2. Re-open the list and select a different item using the mouse
3. Re-open the list using the keyboard

Then the focused item after step (3) is the one that was focused in step (1) rather than step (2).

[robertknight]

Related to this, the docs for the autofocus prop say that focusing is applied when the component is mounted, but the current behavior is that auto-focusing is applied when:

• The component is mounted
• containerVisible changes
• Any of the general configuration props for the hook change (we expect this will not happen for the majority of uses)

[acelaya]

To recap: Every time this effect ran, it reset the selected item to the first one in the list. Now it will reset it to lastFocusedItem.current. This is an improvement over the way it worked before, although lastFocusedItem doesn't currently get updated if you focus an item a different way, eg using the mouse. In the context of SelectNext, this means that if you:

1. Open the list and select an item using the keyboard
2. Re-open the list and select a different item using the mouse
3. Re-open the list using the keyboard

Then the focused item after step (3) is the one that was focused in step (1) rather than step (2).

Hmm, good catch.

There's another problem still to be solved, also related with combining mouse and keyboard (see last checkpoint in #1285).

I'll try to address those together.

Also, I have checked that the behavior you describe does not happen with other arrow-key-navigable components, like Tabs. If you focus one tab via arrows, then click another tab, then focus away, then focus back, the tab that gets focused is the one you clicked. So at least the bug is limited to the Select.