Clicking the floating label was focusing the hidden input via the
standard `<label htmlFor>` behavior. The hidden input's `onFocus`
forwards to `useField`'s `handleFocus`, which set `focused=true` and
selected the first section -- the user-visible bug: a click outside
the field's editable area highlighted the first section.

Block the label's `mousedown` and `click` defaults so it no longer
focuses the hidden input. Screen-reader association via `htmlFor` /
`aria-labelledby` is preserved; user-supplied handlers from
`slotProps.inputLabel` are still invoked.

Reverted the speculative `onMouseDown` plumbing through `useField`
(it didn't address this bug and added churn). The previous commit's
click-handler cleanup in `handleClick` is kept.

Updated tests to cover label clicks (focused and unfocused fields)
and to keep the regression guards for direct section clicks.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The label-mousedown/click preventDefault from the previous commit was a
guess based on a misread of the user's bug. The user clarified that the
actual symptom is clicks "outside the field outline" focusing the field
with a section selected based on click position (left -> first section,
right -> last section), and the label fix did not change that.

Reverting to keep only the original `handleClick` cleanup. I'll leave
the diagnosis open until I have a real reproduction of the click flow
the user is observing.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Chromium has a quirk where clicking on a non-editable element that
visually surrounds a `contenteditable` descendant can still delegate
focus onto that descendant. In the picker fields this manifested as
clicking outside the visible field outline (e.g. on a parent flex
container that centers the field) focusing the nearest section's
`contenteditable` span -- the user-reported bug.

Track the most recent `mousedown` target across the page via a
document-level capture listener (cleared in the next macrotask so
keyboard/programmatic focus isn't gated on stale state). When a
section's `onFocus` fires and the recent mousedown landed outside the
field root entirely, blur the section to undo Chromium's delegation.

Mousedowns inside the field root (including the sections container's
padding, which is how some test helpers open pickers) are still treated
as legitimate field interactions.

Firefox and Safari do not exhibit the delegation behavior, so this
purely fixes the Chromium-only quirk.

See https://stackoverflow.com/questions/34354085/clicking-outside-a-contenteditable-div-stills-give-focus-to-it

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Replace the previous mousedown-tracking + blur-after-focus workaround
with a one-liner: a section's content span is `contenteditable` only
while it is the currently selected section.

This removes the Chromium focus-delegation surface entirely. Chromium
delegates clicks on a non-editable ancestor (e.g. a wrapping flex
container that visually surrounds the field) to the nearest
`contenteditable` descendant; with no editable section in the idle
state, there is nothing to delegate to, so the field stays unfocused.

No flicker (focus is never moved in the first place), no global
listeners, no timeout dance.

Verified that direct section clicks, Tab navigation, keyboard arrow
navigation, typing, and `Ctrl+A` still work -- the active section is
made editable on selection, before `useEnhancedEffect` programmatically
focuses it.

See https://stackoverflow.com/questions/34354085/clicking-outside-a-contenteditable-div-stills-give-focus-to-it

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Several e2e tests opened the field by clicking on the
\`PickersSectionList\` root and relied on Chromium's focus delegation
to forward the focus onto the nearest section's \`contenteditable\`.
The previous commit removed that delegation surface (sections are now
\`contenteditable\` only while selected), so a click on the empty
container no longer focuses anything -- just like a real user clicking
the field's padding rather than its date text.

Update each impacted test to click on the first \`role="spinbutton"\`
inside the relevant container. This better reflects the user gesture
the test is meant to model (clicking on a section to focus it / open
the picker) and is not Chromium-specific.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Replace the previous \`contenteditable\`-toggling fix with the same
pattern React Spectrum uses for its DateField, which is friendlier to
screen readers and lets Playwright's \`fill()\` work without an extra
click.

Sections stay \`contenteditable=true\` whenever the field is editable,
preserving the screen-reader announcement state and keeping the
existing e2e tests working as-is. To prevent the browser from
delegating focus from a click on a non-section ancestor onto the
nearest section's contenteditable:

- The field root attaches an \`onMouseDown\` handler. For primary-button
  clicks landing inside the sections container but NOT on a section
  span, it calls \`event.preventDefault()\` (suppressing the native
  delegation) and manually focuses the section whose horizontal center
  is closest to the click point. This mirrors the native "click
  anywhere on the input focuses the closest editable bit" behavior.
- Each section's \`onMouseDown\` and \`onPointerDown\` call
  \`event.stopPropagation()\` so the parent handler does not fire for
  direct section clicks; native focus on the section is the right
  behavior in that case.
- Adornments (open/clear buttons) live outside the sections container,
  so the parent handler skips them and their own focus/click semantics
  are unchanged.

This is the approach \`useDateSegment\` / \`useDatePickerGroup\` use in
\`@react-aria/datepicker\` -- see
https://github.com/adobe/react-spectrum/blob/main/packages/react-aria/src/datepicker/useDatePickerGroup.ts

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Earlier the section content hooked its own \`onMouseDown\` to
\`stopPropagation\` so that the field root's \`mousedown\` handler did
not run for clicks landing directly on a section. That broke event
propagation that downstream consumers (e.g. multi-input range pickers
opening on click) rely on.

Move the check up to the field root: instead of stopping propagation
on the section, the root's \`onMouseDown\` looks at \`event.target\` and
exits early when the click lands on (or inside) a \`[data-sectionindex]\`
section span. Native focus on the section runs as before, the click
event still bubbles to all the original handlers, and Chromium's focus
delegation is still suppressed for clicks on padding / separator gaps
inside the sections container.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Plain \`contenteditable=true\` on every section left a Chromium
delegation surface: clicks on a non-section ancestor of the field
(e.g. a wrapping flex container in the docs demo) focused the nearest
section. The mousedown handler on the field root only fires for
clicks within the field, so it could not stop those outside-field
clicks.

Make a section \`contenteditable\` only while the field is focused
(or this specific section is the selected one). In the idle state no
descendant is editable, so Chromium has no target to delegate to and
clicks anywhere outside the field are inert. Once the field is
focused -- via Tab, a click on a section, or a click on the field's
padding handled by the root mousedown -- every section becomes
editable, so keyboard editing, programmatic focus, and tools like
Playwright's \`fill()\` keep working uniformly.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…editable

The previous commit gated section-content \`contenteditable\` on the
field's focused state (true when focused, false when idle). That closed
Chromium's outside-click delegation, but it had a real downside: when
React re-rendered between \`mousedown\` and \`mouseup\` to flip the
attribute, Chromium recomputed the click event's target as the common
ancestor of the two phases (the \`FormControl\` wrapper) instead of the
section span. The click event then never bubbled through the
\`PickersInputBase\` root, breaking handlers that depend on it -- most
visibly the multi-input range picker's open-on-click flow, which made
several e2e tests time out waiting for the tooltip.

Replace the attribute flip with a pure CSS rule on the section content:
\`-webkit-user-modify: read-only; user-select: none\` while the field
input root has no \`:focus-within\`. \`user-modify: read-only\` blocks
Chromium's delegation just like \`contenteditable=false\` does, but the
attribute itself stays \`true\` throughout, so the click target stays
on the spinbutton and the rest of the click chain runs normally. As
soon as anything inside the input root receives focus, \`:focus-within\`
flips, the rule is no longer matched, and the spans behave like normal
\`contenteditable\` elements -- keyboard editing, programmatic focus,
and \`fill()\` all keep working uniformly.

Verified with a Playwright reproduction:
- click 100px outside the field outline: no focus moves (idle case)
- click directly on a section: focuses that section
- type into the focused section: characters are inserted

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

This reverts commit 23ec403.

…ui-x into claude/musing-albattani-b80c2f

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…ui-x into claude/musing-albattani-b80c2f

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The CSS rule against Chromium's focus delegation needs trusted pointer
events to be meaningfully verified. Switch the test to drive the click
through `@vitest/browser/context`'s CDP-backed userEvent so the assertion
is about the observable end result (no section is focused after clicking
on an ancestor outside the field root), not the implementation detail.

Adds `@vitest/browser` as an explicit devDependency so vite can resolve
the dynamic import in browser-mode tests (`pnpm test:browser`). The
import stays inside the `skipIf(isJSDOM)` test so it never runs in
`pnpm test:unit`.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…mport"

This reverts commit cf362ad.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The merge of master bumped vitest to 4.1.8, but the `@vitest/browser`
catalog entry this branch added still pinned ^4.1.7, leaving the
catalogs config out of sync with the lockfile. CI installs with
`--frozen-lockfile`, which fails on `ERR_PNPM_LOCKFILE_CONFIG_MISMATCH`.
Regenerate so `@vitest/browser` resolves to 4.1.8, matching the sibling
`@vitest/browser-playwright` / `@vitest/coverage-v8` entries.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>