WPF - ToolTipService.GetBetweenShowDelay ArgumentNullException

[hhu-mahmoud]

Bug Report

The App (Process) terminate. This bug was known and i read it will be solved with .Net 6.0.3.

Now i installed the .Net 6.0.3 but it still terminate the app. See please the exception below.

BTW: I don't use any Tooltip in my App and i deactivated the tooltip in the browser

• What version of the product are you using?

  • CefSharp.Wpf 98.1.210 from Nuget

• What architecture x86 or x64?
  x64

• What version of .Net?
  .Net 6.0.3

• On what operating system?
  Win10

• Are you using WinForms, WPF or OffScreen?
  WPF

• What steps will reproduce the problem?

  • Please provide detailed information here, enough for someone else to reproduce your problem.
    • It's hard to reproduce the problem. It comes during the working.

• What is the expected output? What do you see instead?

  • Not to terminate the app

• Please provide any additional information below.

Application: Project.exe
CoreCLR Version: 6.0.322.12309
.NET Version: 6.0.3
Description: The process was terminated due to an unhandled exception.
Exception Info: 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.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 CefSharp.Wpf.ChromiumWebBrowser.OnMouseDown(MouseButtonEventArgs e) in C:\projects\cefsharp\CefSharp.Wpf\ChromiumWebBrowser.cs:line 2239
at System.Windows.UIElement.OnMouseDownThunk(Object sender, MouseButtonEventArgs e)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
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.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, Object 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 Application.Desktop.App.Main()

[amaitland]

This bug was known and i read it will be solved with .Net 6.0.3.

Please link the relevant issue.

My guess is they didn't fix the problem in all cases. You'll need to get the WPF team to fix the bug.

Closing as not something I can fix, same code works in .Net 4.x

[amaitland]

• https://github.com/dotnet/wpf/blob/869d4e0ec775d51ca50544a2473aafff1c1da813/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Controls/PopupControlService.cs#L569
• https://github.com/dotnet/wpf/blob/869d4e0ec775d51ca50544a2473aafff1c1da813/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Controls/PopupControlService.cs#L602

Should be a fairly simple fix for the WPF team.

[amaitland]

Looks like dotnet/wpf#4623 introduced the bug.

[hhu-mahmoud]

Looks like dotnet/wpf#4623 introduced the bug.

@amaitland The same what I read but it still happend. I made a Ticket by the WPF Team .. but i need a workaround to avoid this problem until they fix it.

it happens now with .Net 6 .. the app was .Net 5 and it runs without problems!

[amaitland]

The same what I read but it still happend

The PR doesn't fix the bug, it is the cause of the bug.

I made a Ticket by the WPF Team .

Please post a link back here for reference.

i need a workaround to avoid this problem until they fix it

You may need to revert to .Net 5.0 until this is fixed.

If the WPF team can provide a workaround then this issue can be reopened.

it happens now with .Net 6 .. the app was .Net 5 and it runs without problems

Rollback to .Net 5 until this is fixed would be the option I'd be considering.

[amaitland]

Issue dotnet/wpf#6319

[amaitland]

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.

Another report of this WPF issue at dotnet/wpf#7002

With this new information it might be worth trying to temp remove the DispatcherTimer see if we can workaround the issue. WPF fix is taking much longer than hoped.

[hhu-mahmoud]

@amaitland
yesterday i wrote a comment, that we changed now (since 5 days) from .net5 to .Net7 (Windows Runtime Desktop Version 7.0.2) and we have no problem until now!

dotnet/wpf#6319

[amaitland]

yesterday i wrote a comment, that we changed now (since 5 days) from .net5 to .Net7 (Windows Runtime Desktop Version 7.0.2) and we have no problem until now!

The problem still exists, they haven't merged the fix yet. There are still three open PRs awaiting review https://github.com/dotnet/wpf/pulls?q=is%3Apr+tooltip+direct+manipulation+fix (targeting different branches)

The demo provided in dotnet/wpf#7002 changed to target .Net 7.0 can be used to easily reproduce the problem. The callstack is essentially the same as you've reported, so hopefully their proposed fix resolves the problem.

From what I can gather they've also introduced the bug into .Net 4.8.1.