UNITY BUG - OnUnhovered - called sporadically, as Z-order swaps Children/Parents in TreeView

[najak3d]

I've changed the title to prefix "UNITY BUG" - if you read below you'll see that this is the conclusion I reached. It ONLY happens inside Unity Editor while "docked OnFocus/Unfocused" modes. Dragging my Game window to it's own separate draggable window or Maximized - this defect does not happen. So my conclusion is -- "unity bug". (2023.2.3f1)

========

I've got a TreeView (you have the code from previous submission). I use "OnHover" to highlight the associated World Content, which looks nice. But as I move the mouse, there are tiny spots where it toggles between seeing the "TreeView Node" and it's child TextBlock.

So my question is this -- what's the best way to make the MouseRay/Hover logic NEVER see the child TextBlock/etc -- but only to see their parent Node, which is the object I'm wanting it to deal with.

I saw property "Navigable" which looks promising, but not sure if this is the right Property, nor even how to set this on a TextBlock, or any other UIBlock? I simply want to designate some UIBlocks as "NEVER HOVERED" -- the hover logic should ignore them entirely, and instead look beyond them to the underlying Parent hierarchy.

Here I'm using the HighlightPlus Outline Effect to outline the Supplier (Green) and Consumer (Red), for a resource demand transaction.

The issue is that the TreeView Highlight as well as the Outlines flicker occasionally, when the "OnUnhover" followed by "OnHover" are called rapidly as I move the mouse horizontally along the Tree View node... it should be keeping the SAME Hover -- no rapid toggling on/off.

I think I could work around this bug by simply setting the child UIBlocks to "not-Hoverable", which is what I'm asking above.

[najak3d]

I think I've semi-diagnosed the root cause of my flicker-issue...

The "hover/unhover" events are auto-triggered whenever I make a call to

  Interaction.RaycastAll(ray, _mouseHits);

I'm doing this now inside of the "Update()" method on our Nova UI's "InputManager.Update()" which calls "UpdateMouse" and I use this call to set "IsMouseOverUI" property for all others to see.

It seems to be a BUG of Nova that a call to "Interaction.RaycastAll(ray, _mouseHits);" would induce an entire Update cycle which can fire Hover/Unhover/etc events.

NOTE-- I think I may be wrong here. The UI events now seem to only be caused by "Interaction.Point(...)", not RaycastAll()..

(I think I just saw it wrong, since both were being called from MouseUpdate() method.)

[najak3d]

I see that this call is the one that ALSO feeds the event system:
Interaction.Point(pointInteraction, LeftMouseButtonValue);

So removing my own RaycastAll() method did NOT fix this for me. It still flickers -- oscillates to thinking I'm hovered over a child UIBlock rather than the parent/etc.

I think this would all be fixed by simply being able to set "which UIBlocks are ignored for the Hover/Unhover" events (and all other events).

My hierarchy at this point shown here is 11 deep (RaycastAll, returns a list of 11 UIBlocks).

By setting "Ignores" to many of these UIBlocks, I could reduce this hierarchy depth, and perhaps that alone would just magically fix this issue.

[najak3d]

I tried changing InputManager.Update() to LateUpdate() - and it only got worse.

I restored it to Update() method, and captured some video here:

NovaUI-Defect-TreeView-HoverFlicker.mp4

And here is the Hierarchy:

[najak3d]

More info here.... This defect does NOT happen if I check "Play Maximized", while for "Play Focused/Unfocused" both produce this defect rampantly. So there is something fragile/unstable about the raytracing while inside the Editor, non-Maximized.

I'm using Unity 2023.2.3f1, now.

[najak3d]

As I move the cursor horizontally, and the flicker begins, I used Log statements to console to tell me the "TopMouseHit" (the first item in the list returned by RaycastAll() that same frame) -- and this result oscillates somewhat randomly to various other UI blocks beneath the top one... The List size is 13, and stays constant, but the ORDER of UIBlocks in this list keeps changing! (normally is correct, but when it flickers, it's because the ORDER is wrong).

Sometimes it returns the BOTTOM MOST root UI element, and sometimes, the "next one beneath" and anywhere in between ... it's not always "the same wrong element" that it returns here.

[najak3d]

ODDLY -- If I simply UNDOCK my Game window, keep it the exact same size -- this defect also goes away.

The thing that triggers this defect is "Docked Non-Maximized" only.

So my temporary workaround here is to:

1. Drag both Game and Scene windows to the same separate window. (not docked)
2. Resize this independent window to be same size as it was docked, and place it overtop the dock.

So it's functionally the same, and only a bit awkward.

This defect seems entirely related to Unity, perhaps only for version 2023.2.3f1.

[drew-512]

Good assessment and analysis najak.

I have been similarly frustrated with Interaction hits coming in out-of-order of UIBlocks and am still awaiting resolution.

[drew-512]

Appreciate the interest but I've almost had it. I've been losing a lot of time implementing stuff that is in Canvas but not in Nova (multi-camera event support, lack of CanvasGroup parity, lack of OnRectTransformDimensionsChange()).

Is there a command that does CalculateLayout() for all a UIBlock's children?

[najak3d]

you wrote: "I've almost had it..."

Not sure how to take this response. Do you have an ETA for when Interaction logic inside a docked-Editor-Window will work correctly? I'd like to know if (and when) this issue might be fixed. I have a workaround, but it's a bit annoying.

[drew-512]

I suspect you have me mistaken for someone on the Nova team. :)

[najak3d]

Bingo. Oops! Any chance you want to share your fixes back to Nova? (assuming this would be useful)

[najak3d]

.... and so my assumption of "public report" was that this was a Unity Editor issue.

For the out-of-order hits, is this cured for you when in Full-Screen mode, or if you simply Undock your Game Window, so that it's free-floating? This works 100% for me (that I can tell).