oωo (owo-lib)

oωo (owo-lib)

29M Downloads

Dropdown components do not capture/consume mouse events (hover or click)

AugustSaintFreytag opened this issue · 1 comments

commented

Dropdown components are one of the many poorly documented parts of owo-lib. It’s still unclear to me if what owo calls a “dropdown” is the whole pairing of something that is always visible and shows the currently selected value and the pop-over with all possible options or only the latter.

Building a GUI screen with a button that opens a dropdown renders correctly but hovering over the pop-over panel also activates inventory slots which highlight on top of the pop-over. Hover events seem to propagate from bottom to top which doesn’t make any sense. Even less fortunately, the same applies to click events which means trying to click an option in the opened dropdown hits anything underneath that also happens to accept click events.

This screen has two dropdowns and the one above is basically unusable because clicking an option in the middle just opens the bottom dropdown so you have two menus at the same time. It’s a mess.

Image
CleanShot.2025-08-11.at.14.22.41.mp4

This is for Minecraft Fabric 1.20.1 on owo 0.11.2+1.20.

commented

I’ve solved it myself.

A solution is to use an OverlayContainer via Containers.overlay(…), add that to the root of the view hierarchy, and then add the dropdown to that. I suspect that’s what the DropdownComponent.openContextMenu convenience function might be doing internally.

My mistake was thinking I could open the menu as a child to the dropdown component itself and the z-index determining what component receives mouse events. In actuality, the view hierarchy is what determines the order of event capturing. You’ve got to think of it in terms of which view comes after which other one, not what you see rendered.

This solves interactions for the open menu over other UI components but not inventory slots that still react to mouse over—my suspicion here is because the highlighting logic is very primitive and doesn’t check if the slot is actually visible, only mouse moved → mouse inside bounding rect → should highlight. To remedy this, I wrote a little subclass of Slot, added an override for canBeHighlighted and made it configurable. I can then get my slot via the handler (CustomSlot) this.handler.getSlot(index) and make it non-interactible.

I still think that you should improve the documentation. I usually need to piece everything together with the GitHub global code search.