Why is this a blocker for T297025? I don't see how this bug affects TypeaheadSearch, because it requires opening the menu while an item is already selected, which is not possible in TypeaheadSearch (because selecting an item also navigates away to a different page).

I'm also not sure what the correct behavior is here. Right now, when you open the menu while something is already selected, nothing is highlighted at first, then when you press the up/down arrow key the item above/below the selected one is highlighted. You're right that this is a little strange, but if we always styled the selected item as highlighted, you'd virtually never see the non-highlighted selected state. It's also consistent with the behavior when you open the menu while nothing is selected, which is that nothing is highlighted at first, then when you press the up/down arrow key the last/first item is highlighted. We could immediately highlight the first item when the menu is opened, but we don't.

@Catrope it's possible if you intentionally open the link in a new tab, and we probably want to cover the scenario where an implementation saves the search term and pre-populates the search box if the user navigates back. That said, this does seem very low priority, and I'm looping in @Sarai-WMDE to weigh in on what the correct behavior should be.

The desired behavior described in this ticket is correct:

• When users reopen a menu after making a selection, they should see the highlighted style applied to the selected item (accent90 background, accent50 text). This after all corresponds to the keyboard placement.
• When users navigate away from the highlighted item (or hover any other options), then this item will display the selected style (accent90 backgroung, base10 text) – until/unless a different selection is made.

(Using the down arrow to open the menu actually allows you to see the correct behavior)

I think that the fix is needed, but I agree this being low priority for TahS.

This made me realise that the current TahS selection in the context of keyboard navigation might not be great:

• In Codex, the last selected value (which, say, was opened in a new tab) displays the highlighted/selected state when the menu is opened again. But, given that the value of the search input is updated as the user navigates through the menu using their keyboard, the previous selection starts to not correspond with the actual selection displayed by the input (the element being highlighted via the keyboard).

Following with the example above: if I closed the menu in the current state and opened it again, I'd still find that the last selection (which doesn't correspond with the input's value anymore) still displays the selected state. I think this is confusing, and that it would make sense to remove the selected state from the item if it doesn't correspond with the value anymore. Thoughts? This for sure should be captured in a separate ticket.

Change 803614 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] [WIP] Menu: Highlight the selected item when menu is opened

https://gerrit.wikimedia.org/r/803614

I created a proof-of-concept to highlight the selected item when the menu is opened (demo here, works for any menu component). I can see Roan's point: when you click to open a menu, you're using your mouse, so you're not actually highlighting the selected item. However, even when you click to reopen the menu, the selected item item is effectively highlighted (if not visibly, in the production version), because if you press the down arrow, you will highlight the item below the selected one.

So, I think the alternative solution would be not to start with the selected item in the case of clicking to open the menu then using the arrow keys to navigate through the items. But then the experience would differ depending on how you open the menu.

Anyway, please play around with the demo and see what you think.,

I think I understand Roan's point and, after meditating on it, I believe that the approach taken in the patch is correct. Specially because it makes both interactive modes consistent:

• When users open a fresh menu (where no selections have been made) nothing should be highlighted yet because the focus is still on the input: the first keystroke allows users to access the menu and highlight the first item.

• When the menu is opened again after a selection has been made (either using a mouse or a keyboard), the keyboard placement is "saved" for convenience, which justifies the application of a highlighted (selected hovered) style to the selected item in both modes.

Just for reference and to support this decision, I checked whether other libraries applied this consistent approach of presenting the same highlighted/selected state whenever a menu is opened via mouse or keyboard. Just some examples: Vuetify's combobox (there are some differences in this case, though, e.g. they don't remove the selected/ highlighted style in case other elements are hovered, only highlighted), headless UI's Listbox (visually quite different, but the behavior's the same). I also noticed that Chrome's default menu also behaves in this same way (e.g. Lightning's Select, Mozilla Protocol's Select, Carbon's Select...). In most cases, the keyboard position is "saved" in the menu even if it's opened using the mouse, although not all DS and libraries apply distinctive styling to selected hovered items like we do (e.g. Mantine's Select).

@Sarai-WMDE Thanks for doing that research and for the helpful summary! I've updated the patch to remove the WIP status so it's ready for code review.

Change 803614 merged by jenkins-bot:

[design/codex@main] Menu: Highlight the selected item when menu is opened

https://gerrit.wikimedia.org/r/803614

The task can be signed-off from a design perspective. The selected/highlighted menu item displays the right styles regardless of the way in which the menu is reopened. Tested in Chrome v103, Safari v15.5 and Firefox v101 on MacOS Monterey.

Testing

This works great now. Using either the keyboard or the mouse selects the item when the menu is opened, with the right highlight colour.

Fantastic - I'll go ahead and resolve this as acceptance criteria is complete and the patch included in Codex 0.1.0-alpha.8 - feel free to reopen if I've missed anything.