I really like working with UI toolkit, but if I had to name the biggest problem I have with it, it’s definitely the focus system. It currently behaves in a very unpredictable manner, with focus requests sometimes ignored, focus unexpectedly lost, focus styling being unintuitive, and focus being difficult to interrogate.
For instance, sometimes when calling Focus() on a TextField element, it just works. Othertimes it doesn’t. There doesn’t seem to be any rhyme or reason. The issue seems to be timing related, possibly because there is some sort of race between user code and underlying UI code. Several people in this forum have proposed work-arounds like using timers or the visual element’s “scheduler” property to defer focus requests. I’ve found that even these work-arounds don’t work 100% of the time.
Another issue is that occasionally a UI document just loses focus entirely for unknown reasons. This is difficult to deal with in a gamepad-controlled game, because once focus is lost, it’s really hard to get back.
Still another issue is how USS stylesheets work with the focus system. Pseudo-selectors like “:focus” are ignored if they are not “specific” enough. We often have to use “:focus:enabled” to get them to work. While I understand why this is the case (“most specific rule is applied”), it’s really hard to know when you’re being specific enough, because it’s not obvious how specific the underlying controls are being with their styles.
I would love to see the UI toolkit team prioritize simplifying and improving the focus system. The focus system is by far the biggest source of UI bugs in our project, and we spend an inordinate amount of time debugging issues surrounding it.
I agree on this. We had to write our own navigation system to handle this much easier (and controllable). Our game is mobile first, but we’re developing it as multi-platform; so we’re supporting gamepads and right now the UI control kinda sucks for gamepads. We managed it to work on lists, modals, etc; but users can touch to the screen, and it’s hard to track/make every VEs focusable or not. UI Toolkit definitely needs a USS property to handle focusable state (or maybe inheritance for focusable on C#/UXML). Caching last focused element etc is logical, but focusing again is not 100% working (as you said) and I can’t find what is wrong sometimes (then brute force trying or delaying to focus on some VE).
Definitely agree the focus system needs work. My solution, or perhaps a way around it, has always been to only have one set of navigable elements at a time. This has influenced my UI design a lot, perhaps for the better, so, silver linings.
You do need to me mindful of visual elements that are kinda secretly focusable. I’ve had to set a few unexpected visual elements focusable property to false via code to prevent gamepad navigation going off course.
I could not get properly focusing elements of ListView’s and all related collection views working via code however, so I had to make my own collection view to work around this.
I also cannot find a way to prevent defocusing on background clicks like you can with uGUI. You would hope that it just respects the Input System UI Input Module’s ‘deselect on background click’ property, but it doesn’t. I pretty much always want a focused element while there is one present, but alas, I need a top level system on my end to manage this.
I’m curious to know more about your solution. Do you have a visual element at the top level monitoring for FocusIn and FocusOut events and then restoring focus when it’s lost?