[Flaky test] toolstriptests.toolstrip_wndproc_invokemouseactivate_success

[runfoapp]

Runfo Tracking Issue: [Flaky test] toolstriptests.toolstrip_wndproc_invokemouseactivate_success

Build	Definition	Kind	Run Name

Build Result Summary

Day Hit Count	Week Hit Count	Month Hit Count
0	0	0

[dreddy-work]

Assert.Equal() Failure\r\nExpected: 0\r\nActual: 2

Stack trace
at System.Windows.Forms.Tests.ToolStripTests.ToolStrip_WndProc_InvokeMouseActivate_Success() in /_/src/System.Windows.Forms/tests/UnitTests/System/Windows/Forms/ToolStripTests.cs:line 7095
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

[dreddy-work]

           using var control = new SubToolStrip();
            var m = new Message
            {
                Msg = (int)User32.WM.MOUSEACTIVATE,
                Result = (IntPtr)250
            };
            control.WndProc(ref m);
            Assert.Equal(IntPtr.Zero, m.Result);
            Assert.True(control.IsHandleCreated);

[lonitra]

WM.MOUSEACTIVATE message for ToolStrip calls to WindowsFormsUtils.LastCursorPoint , which is the cursor position for the last message received.

winforms/src/System.Windows.Forms/src/System/Windows/Forms/ToolStrip.cs

Lines 4919 to 4926 in e0e125a

	if (m.MsgInternal == User32.WM.MOUSEACTIVATE)
	{
	// we want to prevent taking focus if someone clicks on the toolstrip dropdown
	// itself. the mouse message will still go through, but focus won't be taken.
	// if someone clicks on a child control (combobox, textbox, etc) focus will
	// be taken - but we'll handle that in WM_NCACTIVATE handler.
	Point pt = PointToClient(WindowsFormsUtils.LastCursorPoint);
	IntPtr hwndClicked = User32.ChildWindowFromPointEx(this, pt, User32.CWP.SKIPINVISIBLE | User32.CWP.SKIPDISABLED | User32.CWP.SKIPTRANSPARENT);

It is possible that running other tests in parallel cause an unexpected cursor position to be given. We might want to ensure that this test does not run in parallel with other tests.
The cause for this test's flakiness is also likely the same cause for #6610
The cause for this test's flakiness is also likely the same cause for #8611 since MenuStrip's WndProc message will defer to ToolStrip's WndProc

[dreddy-work]

closing against #8864