NavigationMoveEvent not changing focus automatically?

:wave: Hi!
Currently using UIToolkit on Unity 2022.2.17, and Rewired for Input controls

(quick note: I don’t think Rewired is an issue, see here Rewired Documentation | Rewired Standalone Input Module, but I wanted to note that in case people responding found it relevant)

As you can see in the screenshot below, I have the Event Debugger logging the “NavigationMoveEvent” is being received by the currently-focused Play button (as indicated by the size, glow, font color, and X icon), with the direction of Down.

Surprisingly to me, it’s not automatically changing Focus to the below Settings button. Not sure why?

Given this link it says “other than the default ones” – not sure what that means.

I CAN however manually set a direction and a target and it works – but this feels entirely too tedious and laborious to manually set the specific button or focusable in EACH direction on EACH screen. Please tell me I’m doing something wrong lol

And this method above would get especially complex with multiple files / uidocuments where I don’t know of all the buttons or potential layouts of the screen (eg: Maybe there’s a 3x3 grid to the right of the Pause menu or in an Inventory shop – I need to have flawless menu navigation without manually setting each element)

When I was looking at uGUI it seemed there was a concept called Selectable and I’m not sure that currently exists in UI Toolkit / UI Elements?

And/or maybe said another way (aka the title of this thread) – It seems the NavigationMoveEvent isn’t changing focus to the items up/down/left/right (even in a simple 2-button case)

Rewired - Advanced Input for Unity page-179#post-9372464

Someone did suggest possibly creating / re-implementing my own version of the FindSelectable function, but using VisualElements / UIToolkit… However that still feels a bit… Excessive?

Like on every item I want focusable, i would have to register the NavigationMoveEvent, and manually search ALL VisualElements above/below/left/right in order to pick the best possible option?

Hi alexogorek,

At the moment, UIToolkit doesn’t provide a UI to configure what elements should be focused next from any other element and in all the possible directions. Indeed the only way to force a specific behavior is through code like you pointed to in the link to the UIE faq. However, in your particular case, directional navigation should already be jumping to the next element in a direct line in the given direction, provided that it’s focusable, so normally it should select the “Settings” button when going down with the “Play” button focused.

What we mean by the “default” navigation is the behavior that’s there if you don’t intercept the event. The algorithm to find the next element is relatively simple: go in the given direction until you hit a focusable element whose bounding box has a non-zero overlap with the bounding box of the current focused element in the axis perpendicular to the navigation. If you don’t hit any element, wrap around from the other side of the screen and start the search again until you cross the current focused element again or find a valid candidate.

In your case, if “Settings” doesn’t get selected, it may be because 1) it’s not focusable or 2) it doesn’t have the right bounding box, or 3) you’ve just found a bug in UI Toolkit. Make sure your button has “fosable” set to true and doesn’t have “tab index” set to -1.

Interesting note about the tabIndex – I know the focusable is set to true because of UI Debugger showing Hover and Focus classes, plus my USS styling only on Focus so that’s definitely working.

I’ll check the tabIndex as well as see if any things are intercepting that event. Thank you for the reply!

quick question on the tabIndex – do all the elements on screen need to have different values? or can they just all be 0?

Hi! They can all just be 0.

The default navigation is selecting buttons that are contained within a Foldout that is CLOSED.
Is it possible for me to make adjustments to their navigation system to fix this issue myself?

9492088--1336210--upload_2023-11-24_18-56-51.png

Also, I found that this algorithm doesn’t prioritize SIBLING elements in a hierarchy. If I click a Dropdown to open it, and then use a D-pad to navigate downwards several times, it’ll select the first element, the second one, and then instead of selecting the 3rd one (“Save As”), it jumps out of the dropdown and selects the large scrollview because its bounding box is overlapping the currently selected 2nd element.

I also want to be able to make it so that if I have an element within that dropdown focused, and then I navigate to the right, that it should focus the dropdown to the right of it. So this is a fairly complex action in that the system would have to realize that the sibling members are arranged in a vertical fashion, and that navigating to the right should make it go back up the hierarchy to the dropdown root, and then navigate horizontally.

No.

The navigation algorithm called GetNextFocusable2D is contained within NavigateFocusRing.cs which is engine code and it cannot be touched by your unclean hands. Pray and wait for a fix like everyone else. Until then, you have been liberated from the responsibility of ensuring controller compatibility with the user interface.