Have something to say?

Tell us how we could make the product more useful to you.

Drawer.Handle closes all stacked drawers and breaks animation

When using Drawer.Handle with multiple drawers open at the same time, dragging the handle of the top/second drawer to the close action causes all open drawers to close, instead of only closing the drawer being interacted with. Additionally, the close transition is not smooth: the expected drawer animation does not play correctly when the drawer is closed through Drawer.Handle while multiple drawers are open. Steps to reproduce Open a drawer. Open a second drawer on top of the first one. On mobile, grab the Drawer.Handle of the second drawer. Drag it toward the close button/action. Release it. Expected behavior Only the drawer associated with the dragged Drawer.Handle should close, with the normal close animation playing smoothly. Actual behavior All currently open drawers are closed, and the closing animation does not behave smoothly/correctly. This appears to be related to how Drawer.Handle resolves the active drawer when multiple drawers are mounted/open simultaneously.

علی خاکبازان 4 days ago

🐛

Issues

Select: wrong secondary variant invalid background color when focused

Problem When Select.Root is rendered with variant="secondary" and the field is invalid (isInvalid), the trigger background renders with the primary (white/--color-field-focus) background instead of the expected secondary (grey/--default) background. Root Cause: CSS Specificity In @heroui/styles, the invalid state rule nested inside.select__trigger compiles to specificity 0,3,0: /* specificity 0,3,0 */ .select[data-invalid="true"] .select__trigger, .select[aria-invalid="true"] .select__trigger { background-color: var(--color-field-focus); /* primary/white */ } The secondary variant rule only has specificity 0,2,0: /* specificity 0,2,0 */ .select--secondary .select__trigger { background-color: var(--select-trigger-bg); /* --default = grey */ } Since 0,3,0 > 0,2,0, the invalid state always overrides the secondary background — the secondary invalid override is missing.

NicolaCastellani 3 months ago

🐛

Issues

Modal & Alert dialog bug in Chrome related to Dropdown stucking

I found a Chrome-only bug in HeroUI v3 where opening a Modal or AlertDialog directly from a Dropdown item can leave the dropdown popover stuck on screen and still interactive. I could reproduce it reliably in Chrome, but Firefox works fine. The bug happens when the dropdown is closed and the next overlay is opened in the same action. A simple reproduction looks like this: setModalOpen(true)}>Open modal ... In Chrome, the modal opens, but the dropdown overlay may stay mounted instead of cleaning up correctly. It looks like a z-index issue at first, but it seems to be an overlay lifecycle problem, because both overlays can remain in the DOM at the same time. In my case, using Popover instead of Dropdown for this type of action menu fixed it, and so did delaying the second overlay until the first one was fully closed. Also 150ms timeout before opening modal/alert dialog fixes this issue.

mrn0_user 5 months ago

🐛

Issues