ScrollView click sometimes throws when async-waiting for MainLoop-synched MessageBox

[heinrich-ulbricht]

Describe the bug
After #1993 being my fault I put my MessageBox invocations inside Application.MainLoop.Invoke. But since I nevertheless want to await the message boxes I wrote the following helper function that is supposed to allow awaiting the message box:

private static async Task ShowMessageBox (bool isError, ustring title, ustring message, params ustring [] buttons)
{
	var tcs = new TaskCompletionSource<int> ();
	Application.MainLoop.Invoke (() =>
	{
		if (isError) {
			var result = MessageBox.ErrorQuery (title, message, buttons);
			tcs.SetResult (result);
		} else {
			var result = MessageBox.Query (title, message, buttons);
			tcs.SetResult (result);
		}
	});
	_ = await tcs.Task.ConfigureAwait (false);
}

That seems to work. Unless it crashes. See reproduction.

To Reproduce
Steps to reproduce the behavior:

1. Pull/rebuild/look at the repro from heinrich-ulbricht@ba88e7b - it is the modified Reactive sample showing the changes needed to provoke the error (it adds a ScrollView and the async method from above)
2. Launch ReactiveExample
3. Enter values and click on "Login" - the message box appears
   
4. While leaving the message box open click some UI elements

This error should appear:

The error does not always happen. Keep closing, opening and clicking until it happens.

Am I again wrong in some assumptions here? Async contexts etc.? Or should this work? Note that without the scroll view it works fine.

Expected behavior
I expect the error not to happen.

Desktop (please complete the following information):

• OS: Windows 11
• Version: current dev branch

[tznind]

Interesting bug, thanks for raising it! It seems that ScrollView IsOverridden doesn't null check its 'View' object. Here is a unit test that demos the issue.

We could put a null check in but I'm not sure what to return from IsOverridden. Returning true from IsOverridden would do Application.UngrabMouse (); while returning false would result in the mouse event being swallowed.

The thirs option would be to investigate which class is generating the null View mouse event and prevent it releasing events where the clicked View is unknown.

@BDisp any thoughts on this?

[Fact, AutoInitShutdown]
public void ScrollView_WithNullMouseEventView()
{
	var me = new MouseEvent () {
		Flags = MouseFlags.Button1Pressed,
		View = null
	};

	var sv = new ScrollView ();
	sv.MouseEvent (me);
}

[BDisp]

Thanks @tznind, I really didn't write any null check code on this, because I thought it wasn't necessary.
With the @heinrich-ulbricht sample sometimes I get the error, sometimes not. When the MouseEvent.View is null it's supposed the mouse event not to being run. The culprit is when mouseGrabView isn't null it's run mouse event with the null view. I'll fix it.