Repository navigation
[fields] Keep the selected section on blank space clicks - #23318
Conversation
The sections container stretches to fill the field, so a click after the last section lands on it. mui#22285 sent that click to the section whose horizontal center is closest. It chose that behavior on the premise that it matched the native date input. The benchmark in the issue shows the premise was wrong. The native input selects the first section on the first click. Chrome then keeps the current section on every later click in the empty area. This commit aligns the field with that behavior. A 4px tolerance extends the sections on both sides, so a click that just misses the outermost section still selects it. Without the tolerance, a sloppy click 2px past the year does nothing at all. The field padding now follows the same rule. It sits inside the field root but outside the sections container, so the mousedown handler used to return early there and never called `preventDefault`. The browser then blurred the focused section, and the field visibly blurred and focused again. Outside the sections container the handler only claims the field root itself, which is the target of a click on the padding, so the adornments keep their own focus behavior. The active bar gets `pointer-events: none` because it is decorative and overlaps the padding. The rest of the design from that PR stays. Clicks on the container padding and on separator gaps still resolve to the closest section. Only the area past the last section changes. Fixes mui#23304 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LukasTy
added
type: bug
Deploy previewBundle size
Check out the code infra dashboard for more information about this PR. |
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
It is out of scope: the strip behaves as before this PR without it, and a test would need an open range picker and a 2px trusted-input target. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
@codex review |
There was a problem hiding this comment.
Pull request overview
Updates date-field blank-space clicks to match native Chrome behavior while preserving section focus.
Changes:
- Preserves the current section on trailing-space and field-padding clicks.
- Adds a 4px outer-section click tolerance.
- Adds browser and end-to-end regression coverage.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
useFieldRootProps.ts |
Implements blank-space detection and focus preservation. |
selection.DateField.test.tsx |
Tests padding, adornments, boundaries, and selection behavior. |
test/e2e/index.test.ts |
Tests trusted blank-space and padding clicks. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Codex Review: Didn't find any major issues. 👍 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
JCQuintas
left a comment
JCQuintas
left a comment
There was a problem hiding this comment.
The PR description mentions
the native input selects the first section on the first click, and Chrome keeps the current section on every later click in the empty area.
But it seems the first click depends highlight depends on where it is clicked inside the field
Screen.Recording.2026-08-10.at.16.27.28.mov
It probably makes sense, but I wanted to point it out just so we are sure this is the intended behaviour.
|
@JCQuintas, thanks for pointing it out. |
Fixes #23304
Problem
The sections container stretches to fill the field, so a click after the last section lands on it. #22285 sent that click to the section whose horizontal center is closest, on the premise that it matched the native date input. The benchmark in the issue shows the premise was wrong: the native input selects the first section on the first click, and Chrome keeps the current section on every later click in the empty area.
That also left no way to tell a click on the trailing blank space from a click on the year, so a controlled
selectedSectionscould not keep the first section selected.Changes
preventDefault. The browser then blurred the focused section, and the field visibly blurred and focused again, coming back on the first section rather than the one the user had. Outside the sections container the handler only claims the field root itself, which is the target of a click on the padding, so the adornments keep their own focus behavior.Clicks on the container padding and on separator gaps still resolve to the closest section. Only the area past the rendered sections changes.
Testing
Each test was confirmed to fail without its fix.
selection.DateField.test.tsx, browser only, since jsdom rects are 0x0 and no click point can fall outside the sections there: first click selects the first section, a later click keeps the current one, the boundary and the tolerance band both select the year.selection.DateField.test.tsx, jsdom and browser: a mousedown on the field padding is default prevented, and a mousedown on an adornment is not, for both a button and a non-interactive adornment.test/e2e/index.test.ts: the blur and the Chromium focus delegation are browser default actions, so only trusted pointer input reproduces them. Two tests cover the blank space and the padding with real clicks.