Attachment table: keep the search suggestions aligned with the field - #1209
Draft
JeanMarcMilletScality wants to merge 2 commits into
Draft
JeanMarcMilletScality wants to merge 2 commits into
JeanMarcMilletScality wants to merge 2 commits into
Conversation
The suggestion menu took its width from a measurement of the search box, read in a ref callback and held in state. That refreshed on every render but never on a resize that causes no render -- a container query, or a side panel narrowing the content box -- so the menu kept a width the field no longer had. It could not bite while the box was pinned to one width; making the box shrinkable is what exposed it. Anchor the menu to the search container's padding box with left/right insets instead, so it follows the field with no measurement and no state. Both insets set means the used width falls out of the over-constrained equation, which already accounts for the menu's own borders -- so the `- 2` goes too, and the menu now lines up with the field's outer edge instead of sitting a pixel short on each side. Also drops two notes that stopped being true when the box became shrinkable: it is no longer a fixed 287px, and no longer this table's narrowest point.
Contributor
Hello jeanmarcmilletscality,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Contributor
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list: |
…t with the seam The previous commit anchored the menu to `SearchBoxContainer`'s padding box, which is wider than the field, since the field hugs its own content. A `SearchAnchor` wrapper with `width: fit-content` becomes the menu's containing block instead, so `left: 0; right: 0` resolves to the field's width. Measured over one menu held open while the panel resized underneath it with no re-render, 600px down to 220px and back: the menu tracked the field to 0px at every step, against an overhang reaching 95px before. The field's seam with the open menu moves off `:focus-within` onto the menu's own open state. An outside click blurs the input on `mousedown` while the menu closes on the `mouseup` that follows, so a focus-driven seam snapped back under a menu that was still open. `&&` is required on the new rule: `Input` paints its border from `:hover` and `:focus-within`, both of which outrank a single-class `& > div`. Dropping the consumer's `onBlur` also restores downshift's own, which it had been overriding by being spread after `getInputProps()`, so tabbing out of the field now closes the menu. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR — Attachment table: the entity search's suggestion list no longer hangs past the field's edge when the layout narrows, and the field's border and the list now stop being highlighted at the same moment instead of a beat apart.
Context / Why
The suggestion list is anchored to the search box, and until #1201 that box could not change width, so a width measured once was always right. Making the box shrinkable is what exposed the measurement: the field now narrows with its container, and the list did not follow.
🧩 Approach
The width came from a DOM measurement held in React state. It is now two CSS insets on a wrapper that is itself exactly as wide as the field, so there is no width to keep in sync at all.
Before
After
fit-contentis what makes the insets correct: the field hugs its own content, so a wrapper that stretched would put the list on the padding box and leave it wider than the field it belongs to.Measured — one list held open while the panel is resized underneath it, which is the case the old code could not see, since its measurement only refreshed on render:
The field only begins to shrink below about 351px, which is why the defect has a floor and stayed unnoticed. Widening back to 600px recovers in both builds, so the stale value was never permanent — just wrong for as long as the panel stayed narrow.
The second change is when the field stops looking active. Its seam with the open list was drawn from
:focus-within, and the list from its own open state — two different events:mousedownmouseupKeying the seam on the same open state the list uses collapses that into one transition.
🔍 Review focus
organisms/attachments/AttachmentTable.tsx › StyledSearchInput— the&&in the seam rule is load-bearing, not a habit.Inputpaints its own border from:hoverand:focus-within, both of which carry a pseudo-class and outrank a single-class& > div; the old selector won for free because it carried one too. Dropping an&leaves the open state silently unstyled.StyledSearchInputcall sites — the removedonBlurwas spread aftergetInputProps(), so it had been overriding downshift's own blur handler. Removing it hands that back: tabbing out of the field now closes the list, which it did not before.SearchAnchor—position: relativemoved offSearchBoxContaineronto the new wrapper. The list is the only absolutely positioned element in the file, so nothing else changes containing block.🧪 How to test
NarrowPanelattachment story in Storybook.frameWidthcontrol — resize the frame element from devtools, so React does not re-render. The list should stay flush with the field; below ~350px the field shrinks and the list should shrink with it.Follow-up
🔗 References
What changed
Two comments claimed the search box was a fixed 287px and that this was the table's narrowest point; neither has been true since #1201, and leaving them would send the next reader looking for a floor that no longer exists. One is in this file, the other in the
NarrowPanelstory.The
searchInputIsFocusedstate goes with them, along with the list's focused-but-closed bottom border that was its only consumer — with the seam now keyed on the open state, the field keeps its own border in that state and already draws that edge.🤖 Generated with Claude Code