Steps to reproduce
- Render an
AnchoredOverlay with placement="bottom-start" whose content is taller than the space between its target and the bottom of the viewport — a listbox of options, for example.
- Position the target low in the page, so only a few dozen pixels remain below it.
- Open the overlay.
flip / shift move it upward, over or past the target. A consumer who needs the overlay to stay below its target has to opt out of that by pinning the placement — and the only way left to keep the overlay on screen is to compute a max-height by hand, from target.getBoundingClientRect().bottom against window.innerHeight.- As the target nears the bottom of the viewport that computed height trends to zero. At a 768×1024 viewport I measured two such overlays capped at
67px and max-height: 0px — open, focus-trapped, and effectively unusable.
Expected Behavior
AnchoredOverlay should be able to constrain its own height to the space available at its chosen placement, so it stays usable and scrolls internally, without the consumer computing anything.
floating-ui ships size() for exactly this: it reports availableWidth / availableHeight for the resolved placement, which is normally applied as a max-height on the floating element. That middleware does not appear to be in the chain — the published bundle contains no reference to availableHeight or availableWidth, while flip, shift and autoPlacement are all present — and the public props (placement, offset, onPlacementChange, onShiftChange) offer no way to opt into it.
Either applying size() by default or exposing it as a prop would remove the need for consumers to hand-roll a height cap, which is where the zero-height case comes from.
Related: #2146 (closed) covered the other half of this — large overlays being shifted off the top of the viewport. This is the complementary case: a consumer deliberately pins the placement, and then needs the height constrained rather than the position moved.
Steps to reproduce
AnchoredOverlaywithplacement="bottom-start"whose content is taller than the space between its target and the bottom of the viewport — a listbox of options, for example.flip/shiftmove it upward, over or past the target. A consumer who needs the overlay to stay below its target has to opt out of that by pinning the placement — and the only way left to keep the overlay on screen is to compute amax-heightby hand, fromtarget.getBoundingClientRect().bottomagainstwindow.innerHeight.67pxandmax-height: 0px— open, focus-trapped, and effectively unusable.Expected Behavior
AnchoredOverlayshould be able to constrain its own height to the space available at its chosen placement, so it stays usable and scrolls internally, without the consumer computing anything.floating-ui ships
size()for exactly this: it reportsavailableWidth/availableHeightfor the resolved placement, which is normally applied as amax-heighton the floating element. That middleware does not appear to be in the chain — the published bundle contains no reference toavailableHeightoravailableWidth, whileflip,shiftandautoPlacementare all present — and the public props (placement,offset,onPlacementChange,onShiftChange) offer no way to opt into it.Either applying
size()by default or exposing it as a prop would remove the need for consumers to hand-roll a height cap, which is where the zero-height case comes from.Related: #2146 (closed) covered the other half of this — large overlays being shifted off the top of the viewport. This is the complementary case: a consumer deliberately pins the placement, and then needs the height constrained rather than the position moved.