Sorry to drop such a vague issue, I’ve been frying my brain on this for weeks.
We use a 3D widget to present a menu, and a widget interaction component to press and release mouse key’s appropriately. The trouble is whenever we click native objects like scroll bars or buttons, it seems that the focus is given to the widget and it registers the “on key down” event but something then seems to eat the “on key up” event and it leaves our widgets stuck, and none of our key presses work or bubble through the key event in the tree. It’s as if focus is given to something else entirely during key down? I can get around it in a few areas by setting “Receive Hardware Input” to true, though the tooltip states you should never do this for VR, it seems to resolve some of the issues, like dropdown boxes. But there are some instances where it still seems to happen i.e. clicking a scroll bar - it just gets stuck in the “key down” state and forever thinks its holding down left click on the scroll. Any hints would be greatly appreciated.
TLDR: it seems like setting up the Mappable Input Config for OpenXR solved this problem.
Long version for full disclosure:
We wrote a custom system that dynamically switched between different Input configs for different input devices, so whenever a user switches device, it switches the context to a unique setup for the appropriate device in real time so we could reflect this across whatever object needed to know and adapt accordingly. (Though this proved to be a bit of a maintenance nightmare when covering too many devices / contexts, we’re going to have to just setup a unique naming convention for each officially supported controller to achieve what we really want) - Anyhow, a lot of guides specify that you HAD to set the MIC for OpenXR or the keys won’t work at all. Our setup had the reverse issue, they would work fine until we set the MIC, and then they wouldn’t. Not entirely sure why that is. To resolve it, we disabled the dynamic device detection when running in VR mode and just set the context once. Also, I’m not entirely sure why setting the MIC stops the odd widget behavior we were experiencing. If anyone could shed a light on this I’d appreciate it just out of curiosity - It would seem the majority of the issue was with scrollbox widgets. If they were the first component clicked within a parent widget they would eat the focus and not release it until we set the focus to the viewport, however if we pressed a child within that scrollbox first (such as a dropdown box) then this problem would go away, again until we set the focus to the viewport, at which point you could repeat either of the above steps for the same results.