Tooltip Direct Manipulation Fix

[dipeshmsft]

Fixes #
#6319 #7002
Main PR

Description

When an app opens the tooltip directly, WPF ( independently ) also activates the tooltip ( marks it 'current; , registers handlers for Opened and Closed events , sets some internal properties and opens the tooltip ). Now, when app closes the tooltip directly, the closed event is raised.
Now, when the app re-opens the tooltip, WPF decides to dismiss the 'current' tooltip and while doing so, it uses the internal properties, which were unset by the closed event. Thus resulting in the error

In this fix,

1. if WPF sees, that the tooltip is already open, we don't register an Opened handler, but do it's work immediately
2. The closed handler ignores events raised from the "current" tooltip.
3. Move unregistering handler in ClearServiceProperties

Customer Impact

Apps that do direct manipulation of tooltips can crash when run on .NET 6.0+

Regression

Yes, fixes compat regression

Testing

Test pass in progress , Ad-Hoc Testing with sample apps.

Risk

We don't know which real apps/libraries do direct manipulation of tooltips, how they do it, or how they interact with the built-in tooltip management. The examples we have seen some different ways of managing tooltips. And there may be cases that are still not handled with the fix.

Microsoft Reviewers: Open in CodeFlow

[amaitland]

We don't know which real apps/libraries do direct manipulation of tooltips, how they do it, or how they interact with the built-in tooltip management.

I can provide you with one real world example to run your code against

• Checkout the https://github.com/cefsharp/CefSharp/tree/wpf/tooltipdemo in VS2022
• Open CefSharp3.netcore.sln in VS2022
• Make sure build platform is x64
• Change startup project to CefSharp.Wpf.Example.netcore
• Run example
• Hover mouse over the three different buttons to open/close the tooltip

The tooltip code is:

• https://github.com/cefsharp/CefSharp/blob/wpf/tooltipdemo/CefSharp.Wpf/ChromiumWebBrowser.cs#L2137
• https://github.com/cefsharp/CefSharp/blob/wpf/tooltipdemo/CefSharp.Wpf/ChromiumWebBrowser.cs#L2117

I've yet to reproduce the exception reported in #6319
The stacktrace suggests MouseCapture was involved, clicking any of the buttons will trigger a mouse capture.

[batzen]

@dipeshmsft do you still need a repro for testing? I was able to repro this issue reliably while developing a new feature for one of my apps, which targets .NET 7.

[czdietrich]

Any way we can finalize this PR in the close future? The tooltip issue exists for like a year now.
I (and especially several customers) would really appreciate if we can finally bring the fix for those tooltip related crashes.

[dipeshmsft]

@amaitland, thanks for the repro steps. I will test the fix against it. However, I just wanted to clarify about the comment that, we know some ways how direct tooltip manipulation is causing the crashes ( and the fix is based on that ), but there can be more ways which may not be covered with this fix. 

@batzen, it will be good to verify the fix against one more crashing scenario. What are the repro steps in your case ?

[czdietrich]

Hi @batzen, do you have reproduction steps you could share to reconstruct this bug?

It seems like the progress for this bugfix stagnated again and we are uncertain that this fix will make it into the February service pack release. And since we receive crash reports on a daily basis for this issue from our customers, we want to look into work arounds to prevent the crashes in the first place, if this is not being fixed in the framework itself in the foreseeable future.

Just as side note, in our case the crashes seem to occur comparably often in combination with external tools for doing things like screenshots or screen recordings, so the tooltip manipulation might be triggered externally.

So, we would very appreciate if you could share any reproduction steps, so we can look into this. :)

[batzen]

Uh. Sorry. Totally missed the notification.
Will build the repro as soon as i can and share a link here.

[batzen]

Attached is the project to reproduce the issue.
It's a stripped down version of what i am doing in a real application (show a potentially different tooltip for each pixel on a drive map and open/close it immediately).
I found out that the most reliable way to repro is to move the mouse between the control and a grid splitter.
See the gif for a recording of the issue. At the end of the gif the app freezes (indicated by the loading mouse coursor) and crashes afterwards.

WPF_Repro_7333.zip

[dipeshmsft]

@czdietrich, I forgot to update the status of the issue. In our test pass the original fix was failing. I have made some changes and will be rerunning the test pass.
@batzen, thanks for your repro. I was able to verify the fix using your repro. Also, I have added tests on similar lines for this scenario.
@amaitland, however, I wasn't able to reproduce the error in your example.

[czdietrich]

Hi @batzen, thank you for the reproduction steps, this was very helpful.

It took me some time to master it, but after a decent amount of time, I am now able to mime your mouse movements to cause the crash.
I think, it has something to do with the 150ms delay to fade out the tooltip, so the time window to hit is quite small to cause this issue.
It feels like, but I might be wrong here, that it happens less frequently with .NET 7 compared to .NET 6. But still I was able to reproduce it with both runtimes.

If someone just looks for a simple (and dirty) workaround until it is fixed in the framework itself, this exception can be handled and ignored by simply adding something like this to the startup code:

Dispatcher.UnhandledException += (object sender, DispatcherUnhandledExceptionEventArgs e) =>
{
    if (e.Exception is ArgumentNullException && e.Exception.StackTrace?.Contains("ToolTipService.GetBetweenShowDelay") == true)
    {
        e.Handled = true;
        return;
    }
};

[amaitland]

I've yet to reproduce the exception reported in #6319
The stacktrace suggests MouseCapture was involved, clicking any of the buttons will trigger a mouse capture.

@dipeshmsft To clarify I've not been able to reproduce the error myself, there are plenty of reports though in the context of CefSharp. The callstack suggests the mouse was clicked, triggering a mouse capture, which eventually calls CloseTooltip.

The callstack is essentially the same as #7002 (mouse down triggers a capture which closes the tooltip). Have you been able to validate your fix against the demo provided in #7002? If yes then I'd be hopeful that the issue would be resolved.

[dipeshmsft]

@amaitland, yes I have verified the fix against the demo provided in #7002 .

To clarify I've not been able to reproduce the error myself, there are plenty of reports though in the context of CefSharp. The callstack suggests the mouse was clicked, triggering a mouse capture, which eventually calls CloseTooltip.

I did not try clicking the mouse yet. I will take a look at it again and get back to you.

[amaitland]

yes I have verified the fix against the demo provided in #7002 .

Great. To me the callstacks look almost identical, so I'd be hopeful the same fix applies.

I did not try clicking the mouse yet. I will take a look at it again and get back to you.

Unfortunately I don't have a clear set of instructions for you. I've spent hours and have yet to reproduce the problem myself.

The CefSharp source should provide you with one real world example of how the tooltip is being directly manipulated. I appreciate people use API's in ways we never expected/imagined.