You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Observation-class finding split out while fixing #5066 (objectui PR for the percent renderer). Filed unassigned, no pm:queue — nothing here is known to be hit by a user today, and the one instance that WAS hit is fixed by #5066.
HeaderHighlight (objectui packages/plugin-detail/src/HeaderHighlight.tsx) wraps every cell renderer's output in a single clipping span:
block min-w-0 truncate text-sm font-semibold
truncate is overflow:hidden + text-overflow:ellipsis + whitespace-nowrap. The ellipsis half only draws for text in the block's own inline formatting context. When the renderer returns a block-level flex row instead of text, an overflowing flex item is simply cut — no ellipsis, and nothing in the accessible name. #5066 measured exactly that (79px clip box, 32px text node, 25px overflow, 33% reading as 3), so the "clips silently" half of the mechanism is empirical, not inferred.
#5066 fixes the percent renderer from the renderer side: the number gets shrink priority and the decorative bar shrinks away. It deliberately did not take that issue's third suggested route (make the chip itself tolerant of renderers that are not single-line text, or measure before clipping), so the chip-side mechanism is untouched and still applies to every other multi-element renderer.
Candidates, and how far the analysis actually goes
Class-level reading of packages/fields/src/index.tsx only — no browser measurement, because the container this ran in has no Chromium binary. So treat the list as leads, not verdicts:
GeolocationCellRenderer — an inline-flex row: a 14px MapPin plus text like 31.2304, 121.4737 (~110px). In a chip squeezed toward min-w-[7rem] (~72px of content) the tail goes. Because the text sits inside the atomic inline-flex box rather than the chip's own inline context, no partial ellipsis is expected.
ColorSwatchCellRenderer — same shape, 14px swatch plus a 7-char hex. Marginal (~64px), probably fits; listed for completeness.
Renderers whose text carries its own truncate / min-w-0 (lookup, user, file, select-dot — the objectui#3466 family) are NOT affected: the ellipsis draws inside the label.
If someone picks this up
Two shapes, both objectui-only:
Chip-side: stop putting a bare truncate around arbitrary renderer output — e.g. keep the clip but let the renderer opt into its own overflow handling, so a multi-element row is responsible for the ellipsis it can actually draw.
Worth deciding once at the chip, rather than re-litigating per renderer as each one turns up in a highlights strip.
Verification note for whoever takes it: a DOM-only probe reports this surface healthy — the DOM always carries the full value. It needs getBoundingClientRect() plus a screenshot, the way #5066 was measured.
What this is
Observation-class finding split out while fixing #5066 (objectui PR for the percent renderer). Filed unassigned, no
pm:queue— nothing here is known to be hit by a user today, and the one instance that WAS hit is fixed by #5066.The mechanism #5066 fixed only one instance of
HeaderHighlight(objectuipackages/plugin-detail/src/HeaderHighlight.tsx) wraps every cell renderer's output in a single clipping span:truncateisoverflow:hidden+text-overflow:ellipsis+whitespace-nowrap. The ellipsis half only draws for text in the block's own inline formatting context. When the renderer returns a block-level flex row instead of text, an overflowing flex item is simply cut — no ellipsis, and nothing in the accessible name. #5066 measured exactly that (79px clip box, 32px text node, 25px overflow,33%reading as3), so the "clips silently" half of the mechanism is empirical, not inferred.#5066 fixes the percent renderer from the renderer side: the number gets shrink priority and the decorative bar shrinks away. It deliberately did not take that issue's third suggested route (make the chip itself tolerant of renderers that are not single-line text, or measure before clipping), so the chip-side mechanism is untouched and still applies to every other multi-element renderer.
Candidates, and how far the analysis actually goes
Class-level reading of
packages/fields/src/index.tsxonly — no browser measurement, because the container this ran in has no Chromium binary. So treat the list as leads, not verdicts:GeolocationCellRenderer— aninline-flexrow: a 14pxMapPinplus text like31.2304, 121.4737(~110px). In a chip squeezed towardmin-w-[7rem](~72px of content) the tail goes. Because the text sits inside the atomic inline-flex box rather than the chip's own inline context, no partial ellipsis is expected.ColorSwatchCellRenderer— same shape, 14px swatch plus a 7-char hex. Marginal (~64px), probably fits; listed for completeness.percentdisplay renderer's fixed-width progress bar clips the value in a record-highlights chip (33% renders as3) #5066: below roughly 40px of content the bar has collapsed to nothing and the number starts clipping like any other single-line cell. That floor is intrinsic to a self-contained renderer fix — the chip's width is a function of how many chips the record has, so the strip's@containercannot see it.Renderers whose text carries its own
truncate/min-w-0(lookup, user, file, select-dot — the objectui#3466 family) are NOT affected: the ellipsis draws inside the label.If someone picks this up
Two shapes, both objectui-only:
truncatearound arbitrary renderer output — e.g. keep the clip but let the renderer opt into its own overflow handling, so a multi-element row is responsible for the ellipsis it can actually draw.min-w-0 truncateso it ellipsizes in place (the feat(storage): surface sys_file id on upload-complete — ADR-0104 D3 wave 2 (PR-1) #3466 convention), which is the cheap local version.Worth deciding once at the chip, rather than re-litigating per renderer as each one turns up in a highlights strip.
Verification note for whoever takes it: a DOM-only probe reports this surface healthy — the DOM always carries the full value. It needs
getBoundingClientRect()plus a screenshot, the way #5066 was measured.