System.AccessViolationException when using GazeInput.GetGazePointer(null).Click() and GazePointer.IsSwitchEnabled

[DLamb-MagicLeap]

Describe the bug

A clear and concise description of what the bug is.

When using the switch support built into the gaze interaction library the call inside the keydown event handler in client code to GazeInput.GetGazePointer(null).Click() occasionally, but frequently, throws the following error:

System.AccessViolationException: 'Attempted to read or write protected memory. This is often an indication that other memory is corrupt.'

Exception thrown at 0x00007FFD41CA0A17 (Microsoft.Toolkit.Uwp.Input.GazeInteraction.dll) in ---------.exe: 0xC0000005 Access violation reading location 0x000000000000000. occurred.

Stepping through the error it originates in GazeTargetItem.cpp on line 44:

auto provider = GetPattern(peer);

which in turn calls line 31:

auto pattern = peer->GetPattern(P);

• [ no] Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

In an app that leverages the GazeInteraction Library add the necessary code for switch support.

• CoreWindow.Keydown handler
  that triggers GazeInput.GetGazePointer(null).Click() similar to:

        CoreWindow.GetForCurrentThread().KeyDown += new Windows.Foundation.TypedEventHandler<CoreWindow, KeyEventArgs>(delegate (CoreWindow sender, KeyEventArgs args) {                
            if (!args.KeyStatus.WasKeyDown)
            {
                GazeInput.GetGazePointer(null).Click();
            }                
        });
  

and set the IsSwitchEnabled property to true for switch support.

With a switch device attached to you machine, run the application, look at one of the eye gaze enabled controls and click the switch repeatedly trigging the button click.
After a dozen or so clicks the AccessViolationException is typically thrown.

Expected behavior

A clear and concise description of what you expected to happen.

IsSwitchEnabled should reliably trigger the button click event via switch when enabled as the dwell event does when not.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

NuGet Package(s): 

Package Version(s): 

Windows 10 Build Number:
- [ ] Fall Creators Update (16299)
- [X ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] Insider Build (build number: )

App min and target version:
- [ ] Fall Creators Update (16299)
- [X ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] Insider Build (xxxxx)

Device form factor:
- [X] Desktop
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio 
- [X ] 2017 (version: )
- [ ] 2019 (version: ) 
- [ ] 2019 Preview (version: )

Additional context

Add any other context about the problem here.

[michael-hawker]

@peteams looks like there's a lot of details here, is this something you have time to look at before our 10/10 release?

[peteams]

There are two issues here.

There was an issue that provoked the situation that GazeInput failed to handle. Specifically, the KeyDown handler was added multiple times, once per instantiation of the page. That caused Click to be called multiple times. Resolving that resolves the exception being fired.

The issue within GazeInput is that there is an assumption that (a) controls don't change type and (b) their corresponding automation peer always has the same type. While (a) is true, (b) was false in the problem case because the control lost it's automation peer. The first Click activation caused the control to be changed in several ways (possibly moved, disabled, hidden) and that meant no automation peer applied to the control.

There is a simple fix, to check that GetPattern does not return null when the control is being invoked. However, there may be deeper issues, so I will not apply this fix until it has been properly thought through.

[michael-hawker]

@VisualByteStudios did @peteams workarounds help you resolve your issues?

[DLamb-MagicLeap]

@michael-hawker , as @peteams mentions above, I don't believe he has applied a fix to the GetPattern issue as he was worried that there might be deeper issues.
So no I wouldn't say the issue was resolved. Personally I ended having to write my own local implementation of switch support for my needs.

[michael-hawker]

Thanks @VisualByteStudios, I misread @peteams statement.

Does your implementation resolve the concerns @peteams had brought up? Would it make sense to contribute back to the toolkit here?