[autocomplete] Improve highlight tracking and selection state#48219
[autocomplete] Improve highlight tracking and selection state#48219mj12albert wants to merge 4 commits intomui:masterfrom
Conversation
mj12albert
added
type: bug
Netlify deploy previewhttps://deploy-preview-48219--material-ui.netlify.app/ Bundle size report
|
| if ( | ||
| highlightedIndexRef.current !== -1 && | ||
| popupOpen && | ||
| shouldSelectHighlighted && | ||
| // After a touch-scroll the highlight is stale (the user scrolled | ||
| // past it), so skip selection until the next deliberate interaction. | ||
| !touchScrolledRef.current | ||
| ) { |
mj12albert
force-pushed
the
autocomplete/highlight-and-selection-1of5
branch
2 times, most recently
from
c4c814d to
587749d
Compare
mj12albert
force-pushed
the
autocomplete/highlight-and-selection-1of5
branch
from
587749d to
b04c1f0
Compare
| // Auto-select the highlighted option on blur, but only if the highlight | ||
| // came from keyboard navigation or was set programmatically (autoHighlight). | ||
| // Mouse hover and touch should not trigger selection — the user may have | ||
| // moved the pointer over an option without intending to commit to it. |
There was a problem hiding this comment.
Looking at this and the related test: (should not select a mouse-hovered option on blur even if already highlighted) i.e autoSelect + autoHighlight prop combination.
Right now, the first auto-highlighted option is not selected on blur if it was mouse-hovered, but is selected if it wasn't hovered. This feels inconsistent and confusing.
Instead, if autoHighlight is active (first option highlighted), it should be selected on blur regardless of hovered over that option or not.
The “don't select on hover + blur” behavior should apply only to other (non auto-highlighted) options.
There was a problem hiding this comment.
I don't agree with changing this behavior in this PR, mouse hover alone should not commit a value on blur.
IMO the fact that the hovered option happened to already be autoHighlight-ed does not make it a stronger/deliberate intent of user selection
There was a problem hiding this comment.
Do we have an official spec for this somewhere which we can follow?
| } else if (popupOpen && touchScrolledRef.current) { | ||
| // The highlight is stale from a touch-scroll — close without selecting. | ||
| event.preventDefault(); | ||
| handleClose(event, 'escape'); |
There was a problem hiding this comment.
Is escape reason correct here? Since we are closing on Enter with mobile keyboard.
There was a problem hiding this comment.
Technically no, but we don't have a Esc close reason and this is the closest while strictly avoiding breaking changes
Though we could widen the type and it should be safe
There was a problem hiding this comment.
This looks a very rare case where this will trigger so as to widen the types, but it's up to you.
| // Called after handleOpen so it overrides handleOpen's setInputPristine(true) | ||
| // when the first keystroke also opens the popup. | ||
| if (valueChanged) { | ||
| setInputPristine(false); | ||
| } |
There was a problem hiding this comment.
Is this a separate regression or it's covered in the tests above?
3 participants
Fixes #20602
Fixes #27137
Fixes #46718
Adds
highlightReasonRefinternally to better handle edge cases created by the item highlight and other interactions.Codex suggests using pointer events as a better touch/mouse detection strategy to what is currently being used, which is more robust for hybrid devices (iPad with a bluetooth keyboard) but we could do that separately.
Manual testing steps:
1.
autoSelectshould not select mouse-hovered options on blur: #20602autoSelectvia the code editorExpected: No option selected — input stays empty
Current: The hovered option IS selected — its value appears in the input after blur
Variation with
autoHighlight:autoSelectandautoHighlightExpected: No option selected (the hover overrides the programmatic highlight reason)
Current: The first option is selected on blur, even though the user only hovered over it.
2.
freeSoloEnter should prefer typed text over auto-highlighted match #27137Expected: "The Godf" is accepted as free text, NOT "The Godfather"
Current (master): "The Godfather" is re-selected (the full original value), not "The Godf". The programmatic highlight from syncHighlightedIndex (which matches the old value) wins over the typed text.
3. Touch-scroll + Enter selects wrong item #46718
This requires a touch device + software keyboard
Expected: Popup closes with no option selected
Current (master): The option that was under the initial touch point (before scrolling) is selected. The stale highlight from touchstart is persisted through the scroll, and Enter commits it.