LogUIActionRouter: Warning: LeafmostActiveNode not updated.

I see this warning:

LogUIActionRouter: Warning: LeafmostActiveNode not updated.

in our logs, and I’m wondering how serious that is and what exactly I need to do to get rid of that warning.

It seems to be caused by an activatable widget returning null from GetDesiredFocusTarget in a blueprint when that widget is being deactivated. I don’t see any misbehavior from the UI after this, focus is properly updated as far as I can tell.

Any clues would be appreciated, or hints on what I should do to give you more information. I’m tempted to downgrade this warning, but if this is something I should take seriously I can try to generate a proper repro case.

Steps to Reproduce
I’m not sure exactly what triggers this warning, but it may be caused by an activatable widget return null from GetDesiredFocusTarget in a blueprint when that widget is being deactivated.

Hi,

It’s possible that the warning is harmless depending on what is happening at the moment it fires, but the scenario we’re trying to warn about is a UI softlock where focus can’t be routed properly and ends up somewhere unwanted (or somewhere it can get stuck) since that can be a big problem on platforms without a mouse. Essentially, CommonUI builds a tree and sets focus to the leafmost activated widget, which should be the widget on top of all others. When that widget is deactivated, we look for a new leafmost widget to set focus to, and that widget applies it’s own input configuration if needed to customize how input will work at that “level” of the interface. You can set LogUIActionRouter to Verbose to verify, but what is likely happening here is multiple widgets are deactivating and the router is trying to set focus to a newly deactivated widget (and failing). This is probably fine if that widget’s deactivation causes another call to UpdateLeafNodeAndConfig and the second call is successful, we send a warning in case something has gone sideways and we can’t find any valid focus target.

If you have a reliable repro case, I’d recommend enabling that logging just to verify which widget is failing to receive focus so you can confirm that the router will always be redirected to some other leaf node. If it’s an expected scenario (like deactivating multiple widgets at once) then it should be safe to downgrade the warning.

Best,

Cody