fix(ui): fix Select keyboard navigation — first arrow key press now highlights first item

[franzheidl]

DO NOT MERGE YET – SEE COMMENT

Problem

When using the keyboard to navigate the menu of a Select, it takes hitting the arrow-down-key multiple times before the first item was visually focussed. With the hits before items were focussed, too, but without any visual display, which is highly confusing.

Root Cause

Dropdown options were always mounted in the DOM, hidden via display: none on the Floating UI container. Headless UI's DOM-order sort ran against elements in a hidden subtree on page load, producing an unreliable option order. On first open, goToOption couldn't resolve the correct active index and the first few arrow-down presses had no visible effect.

Fix

• Conditionally render the portal only when open ({open && createPortal(...)})
  so options mount, register, and sort against visible DOM elements
• Switch SelectOption from as={Fragment} to as="li" so HUI owns the
  element and sets data-active natively
• Add tabIndex={-1} to the floating container to exclude it from sequential
  keyboard focus order

Closes #1781

Test plan

• Open Select via keyboard, first arrow-down immediately highlights item 1
• Open Select via mouse, item 1 (or selected item) is highlighted immediately on open
• Arrow-up/down, Enter, Escape, Tab all behave correctly
• Multi-select keyboard navigation works
• No visual regressions in Select stories

Checklist

• I have performed a self-review of my code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have made corresponding changes to the documentation (if applicable).
• My changes generate no new warnings or errors.
• I have created a changeset for my changes.

PR Manifesto

Review the PR Manifesto for best practises.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 1e0673b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://cloudoperators.github.io/juno/pr-preview/pr-1798/
Built to branch gh-pages at 2026-07-15 09:05 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[franzheidl]

DO NOT MERGE – RAW VALUES IN LABELS REGRESSION:

Potential regression: pre-selected label shows raw value until dropdown is first opened

With {open && createPortal(...)}, SelectOption children only mount when the dropdown opens. Their useEffect that calls addOptionValueAndLabel therefore doesn't fire until first open, leaving optionValuesAndLabels empty on initial render.

getDisplayValue (line 465) falls back to valueLabel || value || placeholder when the map has no entry for the current value — so a controlled <Select value="opt-1"> with <SelectOption value="opt-1" label="Option One" /> will render "opt-1" in the toggle button on load instead of "Option One". Multi-select is worse: getMultipleDisplayValues returns an empty string for all pre-selected options before first open.

One clean fix would be to replace the effect-based registration with a useMemo that walks children directly using React.Children.forEach at render time, so the map is populated independently of whether the portal has mounted. This would also eliminate the N setState calls per open cycle as a side effect, since addOptionValueAndLabel and its useEffect in SelectOption could be removed entirely.

---

Minor: tabIndex={-1} placed after {...getFloatingProps()} silently overrides any tabIndex Floating UI emits

As of the current Floating UI setup (useClick + useDismiss) neither hook emits a tabIndex, so this is benign right now. But with tabIndex={-1} appearing after the spread, any future interaction hook (e.g. useListNavigation) that sets a tabIndex for focus tracking would be silently clobbered. Placing tabIndex={-1} before the spread, or passing it through the Floating UI API as {...getFloatingProps({ tabIndex: -1 })}, is the safer pattern.