Tooltip throws ArgumentNullException

• .NET Version: 6.0.8
• Windows version: 10.0.19042 Build 19042
• Does the bug reproduce also in WPF for .NET Framework 4.8?: No (Can be also tested with the attached demo.sln by changing the target framework)

Problem description: If a tooltip has been closed by timer and directly afterwards a mouse click action like CaptureMouse will be triggered an ArgumentNullException will be thrown. Can be not reproduced with .Net Framework 4.8.

Bug looks similar to this bug, which has been already fixed: https://github.com/dotnet/wpf/issues/6319 But bug still exists by doing different repro.

Actual behavior: App crashes with the following exception:

System.ArgumentNullException: Value cannot be null. (Parameter ‘element’) at System.Windows.Controls.ToolTipService.GetBetweenShowDelay(DependencyObject element) at System.Windows.Controls.PopupControlService.CloseToolTip(ToolTip tooltip) at System.Windows.Controls.PopupControlService.OnPostProcessInput(Object sender, ProcessInputEventArgs e) at System.Windows.Input.InputManager.RaiseProcessInputEventHandlers(Tuple`2 postProcessInput, ProcessInputEventArgs processInputEventArgs) at System.Windows.Input.InputManager.ProcessStagingArea() at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input) at System.Windows.Input.MouseDevice.Synchronize() at System.Windows.Input.MouseDevice.ChangeMouseCapture(IInputElement mouseCapture, IMouseInputProvider providerCapture, CaptureMode captureMode, Int32 timestamp) at System.Windows.Input.MouseDevice.Capture(IInputElement element, CaptureMode captureMode) at System.Windows.UIElement.CaptureMouse() at ToolTip.MainWindow.OnMouseLeftButtonDown(Object sender, MouseButtonEventArgs e) in D:\Workspace\Software\ToolTip\ToolTip\MainWindow.xaml.cs:line 64 at System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget) at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target) at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs) at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised) at System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender, RoutedEventArgs args, RoutedEvent newEvent) at System.Windows.UIElement.OnMouseDownThunk(Object sender, MouseButtonEventArgs e) at System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget) at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target) at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs) at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised) at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args) at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args) at System.Windows.Input.InputManager.ProcessStagingArea() at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input) at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport) at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel) at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, O bject args, Int32 numArgs, Delegate catchHandler) at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam) at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg) at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame) at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame) at System.Windows.Threading.Dispatcher.Run() at System.Windows.Application.RunDispatcher(Object ignore) at System.Windows.Application.RunInternal(Window window) at System.Windows.Application.Run() at ToolTip.App.Main()

Expected behavior: App should not crash.

Minimal repro: Please use the attached demo.sln and run it with .net 6 target framework. After the app window appears move your mouse into the window. A tooltip will be shown, which shows you the actual mouse position. Stop moving the mouse and wait 5 seconds until the tooltip disappears. Directly and quickly after the tooltip disappears quickly move your mouse a short distance and afterwards quickly do a left click.

Attached demo.sln: ToolTipBug.zip

[SamBent]

Yes, this helps a lot. This is the repro (and time-travel trace, sent by @miloush privately) I’ve been waiting for since March.

It’s a dupe of #6319 in the sense the root cause is the same: the app and WPF’s PopupControlService are both manipulating the tooltip object (setting toolTip.IsOpen), and sometimes confusing each other in the process. The details of how the manipulation happens might be different, but that doesn’t matter much.

Some notes:

• Bug 6319 is not fixed. There are some references there to other bugs that have been fixed, but the crash while trying to get the owner’s BetweenShowDelay has not been addressed.
• All versions of .NET (at least back to 4.5, and probably farther) react to the ToolTip.Closed event by resetting the (internal) Owner property to null, even when the event is initiated by the app’s direct manipulation. It seems to be just luck that this didn’t lead to ANE crashes - there are no comments, tests, or any evidence that anyone knew that Owner was fragile in the presence of direct manipulation. The code just happened to work.
• The ANE crash also occurs in .NET 4.8.1. Not surprising, since it contains the same new code as .NET 6.0. That code affects all apps, regardless of TargetFrameworkVersion.
• Apps that manipulate tooltips directly are unlikely to get the benefit of the new WCAG 2.1-compliant behavior. They could get failing grades on accessibility tests.

[dipeshmsft]

@cmunforte @czdietrich @JNaumann86 we have merged the fix in the release branches and the fix will be out in upcoming servicing release of .NET 6 and .NET 7.