Mixedrealitytoolkit-unity: [Beta] vNext UI events do not propagate the same as vanilla Unity

[phosphoer]

Does this affect the legacy HoloToolkit (master) or the Mixed Reality Toolkit (mrtk_release)?
Mixed Reality Toolkit vNext

Describe the bug
In vanilla Unity UI with the Standard Input Module + mouse input, a pointer enter event will propagate up the hierarchy such that if you have a Button who's target graphic is a child, the button will respond to the child graphic being hovered.

When using a pointer input from the MRTK such as the GazeProvider, this is not the case, and pointer enters on child graphics of buttons are ignored. Something about the way the input is handled requires that the Button target graphic be on the same game object, which is likely incompatible with a lot of existing UI hierarchies in projects today.

To Reproduce
Repro project
Steps to reproduce the behavior:

1. Download the repro unity project and open it with latest Unity 2018
2. Open Scenes/unity-ui and hit play
3. Verify that mouse hovering both buttons produces a highlight effect
4. Open Scenes/mrtk-unity-ui and hit play, the gaze camera should start panning left and right
5. Observe that the button using a child graphic is not highlighted, but the sibling one is

Expected behavior
Both buttons are highlighted by the gaze provider

Actual behavior
Only buttons with sibling graphics are highlighted by gaze

Unity Editor Version
2018.2.14f1

Mixed Reality Toolkit Release Version
vNext development beta

[StephenHodgson]

This would likely also affect HTK as well as the propagation pattern didn't change.

[StephenHodgson]

I think this might have more to do with the raycast order than event propagation, but I could be mistaken.
I also need to port the raycasting/graphic raycasting unit tests over from HTK as well.

[StephenHodgson]

@phosphoer thanks for the report. I'll look into this when I get a chance. If you have some fixes already in mind/ready to go, you're more than welcome to open a PR as well.

[phosphoer]

Digging into this further, it may be related to #3218.

In FocusProvider.cs, UpdateFocusedObjects():

foreach (var pointer in pointers)
{
    if (pointer.PreviousPointerTarget != pointer.CurrentPointerTarget)
    {
        pendingPointerSpecificFocusChange.Add(pointer);

        // Initially, we assume all pointer-specific focus changes will
        // also result in an overall focus change...

        if (pointer.PreviousPointerTarget != null)
        {
            pendingOverallFocusExitSet.Add(pointer.PreviousPointerTarget);
        }

        if (pointer.CurrentPointerTarget != null)
        {
            pendingOverallFocusEnterSet.Add(pointer.CurrentPointerTarget);
        }
    }
}

Debugging into this, there are never any new focus enter objects. CurrentPointerTarget is always null. and PreviousPointerTarget is always non-null when hovering an object, seems they may be flipped somehow? Furthermore, every frame that the pointer is over the button, it sends a focus exit event for it, yet somehow the button gets into its focus state anyway despite a focus event never being sent. I'm not familiar with the internals of mrtk so I don't have an intuition on what might be the root of this, but will keep looking.

I'm a bit curious about the design of keeping the StandaloneInputModule in conjunction with your input system. If you are sending pointer enter/exit events yourself, which is also the job of the InputModule, how do you avoid conflicting with it? You'll constantly be receiving normal mouse input in the editor and in builds regardless of any configuration in MRTK, no?

[phosphoer]

I figured it out, the UpdateHit() for PointerData that is used for graphics raycasting was missing the line CurrentPointerTarget = Details.Object. I added that and it fixes this issue. I'll make a PR soon.

[StephenHodgson]

I'm a bit curious about the design of keeping the StandaloneInputModule in conjunction with your input system. If you are sending pointer enter/exit events yourself, which is also the job of the InputModule, how do you avoid conflicting with it? You'll constantly be receiving normal mouse input in the editor and in builds regardless of any configuration in MRTK, no?

Seems like a separate issue/proposal. I remember there being really good reasons for this (I think updating an existing project was one of them) but I can't think of all of them off the top of my head. You might find some answers by searching around old issues.