Haz

When [`virtualFocus`](https://ariakit.org/reference/select-provider#virtualfocus) is `true` (the default on `Select`), the widget requires an element to receive the actual DOM focus. The items are then focused using the `aria-activedescendant` attribute. `ComboboxList` isn't...

We don't explicitly support this setup (tabs within a menu) at the moment. It should be possible, but we'd need to experiment with it more. For example, the `menu` >...

I asked for specifics on your use case so we can create relevant examples. Simple reproductions are great for bug fixes and small adjustments, but new features need to be...

The modified behavior should apply to Menu as well, but I don't think the current implementation is correct. The workaround proposed by @benrodrs in https://github.com/ariakit/ariakit/issues/4324#issuecomment-2574098303 is closer to how native...

The combobox is not designed to open on focus. It opens on pointer down. If you want it to open on focus, handle it manually: ```tsx const [open, setOpen] =...

Thanks for reporting this! This happens because the selected item element gets reappended to the DOM, which triggers its `autoFocus`. You can work around it by explicitly setting the `autoFocus`...

Thanks for the detailed reproduction. We should probably track the scroll position within the combobox input. In the meantime, you can use this workaround: ```jsx { event.target.scrollLeft = event.target.clientWidth; }}...

That's expected given how React works. The `onClick` event is a special type of event called a "discrete event" in React. Any state update inside a discrete event flushes effects...

I tried to implement a solution in userland that covers most, if not all, combinations. It seems to work: https://stackblitz.com/edit/xw2vog-5rmvxa?file=menu%2Findex.jsx This approach uses the DOM as the source of truth,...

@ciampo There are plans, and yes, it will integrate with Combobox. However, there's no ETA. It should already be achievable in userland, though.