Repository navigation
fix(ui-ng): make flr-menu keyboard navigable - #679
Conversation
Focus the first item on open, add arrow/Home/End navigation, close on Tab and restore focus to the trigger. Drop role=menu from the inline brand dropdown, which is a plain list of links.
There was a problem hiding this comment.
Both earlier findings are fixed in 41f6956, and the threads are resolved.
Nit: withTypeAhead() does nothing as written. The FocusableOption objects built in options have no getLabel, and the key manager needs that method to match typed characters. Either add getLabel to MenuItemComponent (return the .flr-menu-item__label text through a viewChild) and map it into options, or drop withTypeAhead().
There was a problem hiding this comment.
ae9fb3a looks right: caching options per item in the WeakMap keeps the references stable, so FocusKeyManager keeps the right active item when the item list changes.
There was a problem hiding this comment.
49b5ab3 only touches the story. Sending keyCode matches what FocusKeyManager reads. The custom keyboardMap replaces user-event's default map, but the story only presses the six keys it lists, so that is fine.
The trigger host is a custom element and not focusable. Story now dispatches keydown with keyCode, which user-event omits.
There was a problem hiding this comment.
a41b908 looks right. onDetach now focuses the trigger itself when it can take focus, and otherwise the first focusable element inside it. That covers a custom-element host like <flr-button flr-menu-trigger>. The story's press() sets keyCode explicitly, which is what FocusKeyManager reads.
## [1.45.1] - 2026-10-25 ### Bug Fixes - fix(ui-ng): make flr-menu keyboard navigable (#679)
Closes #675
Not run locally: test-storybook fails to load the @swc/core native binding on this machine. Storybook builds and the showcase typechecks.