search

cefsharp / CefSharp

.NET (WPF and Windows Forms) bindings for the Chromium Embedded Framework
http://cefsharp.github.io/
Other
9.87k stars 2.92k forks source link

WPF - ToolTipService.GetBetweenShowDelay ArgumentNullException #4048

Closed hhu-mahmoud closed 2 years ago

hhu-mahmoud commented 2 years ago

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

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 commented 2 years ago

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 commented 2 years ago

Should be a fairly simple fix for the WPF team.

amaitland commented 2 years ago

Looks like https://github.com/dotnet/wpf/pull/4623 introduced the bug.

hhu-mahmoud commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Issue https://github.com/dotnet/wpf/issues/6319

amaitland commented 1 year ago

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 https://github.com/dotnet/wpf/issues/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 commented 1 year ago

@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!

https://github.com/dotnet/wpf/issues/6319

amaitland commented 1 year ago

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 https://github.com/dotnet/wpf/issues/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.

amaitland commented 1 year ago

Starting in version 110 you can override OnTooltipTextChanged to provide a custom behaviour for opening of the tooltip. The OpenOrCloseToolTip protected method is the one used to open and close the tooltip internally.

Something like the following will open the tooltip directly without using the DispatcherTimer which may workaround the issue in WPF. I've not been able to confirm this resolves the issue, if you go down this path then please report your findings below.

internal class ChromiumWebBrowserEx : ChromiumWebBrowser
{
    protected override void OnTooltipTextChanged(string oldValue, string newValue)
    {
        if(string.IsNullOrEmpty(oldValue) && string.IsNullOrEmpty(newValue))
        {
            return;
        }

        OpenOrCloseToolTip(newValue);
    }
}
amaitland commented 1 year ago

PR #4389 will add a means to configure the delay before the tooltip opens, when merged you'll also be able to set the delay to 0 so the tooltip opens immediately.

cmunforte commented 1 year ago

So we have been getting this crash at least 30 times per day. We have a WPF application that hosts the CefSharp Chromium browser. So after a bit of fiddling around I was able to fix this crash within our code by attaching to the "ToolTipOpening" event and setting "e.Handled" to true. 

public ChromiumWebBrowser Browser;
this.Browser.ToolTipOpening += this.OnToolTipOpening;

private void OnToolTipOpening(object sender, ToolTipEventArgs e)
{
         // Fixes the System.ArgumentNullException within System.Windows.Controls.ToolTipService.GetBetweenShowDelay
         // Funnily enough it still shows the tooltip!
         e.Handled = true;
}

This is our setup:

Not sure why it works but thought it might help others.