Exception opening right click menu if tooltip is shown

Version: 6.0.100 Commit: 9e8b04bbff OS Build 22000.318

• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes/No No, this did not reproduce with previous .NET versions

• Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc…)? If yes, please file the issue via the instructions here. Does not appear to be tooling related.

Problem description: Our application has started throwing exception after the update to .NET 6 with VS 2022. The issue occurs when the application is attempting to open a right click menu while a tooltip is active. The repro case is not reliable and may be timing sensitive.

System.ArgumentNullException HResult=0x80004003 Message=Value cannot be null. (Parameter ‘element’) Source=PresentationFramework StackTrace: 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.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 ArpsEditor.App.Main()

Expected behavior: No exception, same as behavior in .NET 5.

Minimal repro:

[SamBent]

Thank you, @randalvs. Your repro illustrates what I was missing - how a ToolTip can have both IsOpen=true and Owner=null. It’s because your app manipulates the tooltip’s Popup directly (via the storyboards in your custom style). It sets Popup.IsOpen=false, which causes the tooltip to clear its (private) Owner property but doesn’t change ToolTip.IsOpen. The crash occurs when the tooltip itself is closed.

I suspect all the complaints here boil down to the same thing: closing the tooltip’s Popup directly (as opposed to closing the ToolTip object, and letting the PopupControlService close the Popup in response). It’s not easy to do, as the Popup (and often the ToolTip itself) are private, but your repro shows one way to do it. I still don’t see how it happens in the original case involving ContextMenu, but the fixes I’m contemplating will protect against any direct Popup manipulation, no matter how they’re caused.

I’m not sure if this is the correct way to change the styling of the popup

A custom implicit style is fine for changing the visual appearance (colors, fonts, layout) of the Popup, but it’s not so good for changing its behavior. I see some problems, some of which are present already in .NET 4.8, 3.1, and 5.0, and some made worse by the new ToolTip behavior in .NET 6.0. The style defines a very specific behavior, akin to the old default tooltip behavior from, say, .NET 4.5. Some consequences:

• It applies the “tooltip-ish” behavior to all Popups, even those that don’t belong to a ToolTip.
• It ignores the tooltip properties InitialShowDelay, ShowDuration, etc. and interacts with those properties in potentially confusing ways. For example, WPF starts the BetweenShowDelay timer when the ToolTip closes, which with your behavior can be much later than when the Popup closes, leading to unexpected delays (or lack of delays) when mousing between controls that have tooltips.
• It doesn’t support new tooltip behavior, and can actually interfere. For example, it breaks keyboard navigation behavior: tabbing into a TextBox opens its tooltip (since .NET 4.8).
• It doesn’t comply with the latest accessibility requirements. For example, WCAG 2.1 requires that a tooltip is “hoverable” and “persistent”, i.e. stays open while the user moves the mouse from the owning control to the tooltip (in order to move the scope of Magnifier to the tooltip).
• It can re-open the Popup even after the ToolTip has closed. Because the storyboards only care about mouse position, and not about the state of the ToolTip.

The existing tooltip properties provide quite a bit of flexibility in controlling the behavior of the tooltip (and its Popup). You should use them, rather than styling Popup.

[SamBent]

@dragnilar My PR will fix the crash (in WPF itself). WPF probably cannot address the other problems - if a third party overrides accessibility behavior, they are responsible for adapting to the latest requirements. So if you’re having accessibility issues because DevExpress changes popup behavior, definitely make DevExpress aware.

That said, it’s not always easy to know whether a given problem is caused by a third party, WPF, or the app itself. And when WPF changes accessibility behavior (or any behavior), we try not to break existing overrides and workarounds, but that’s not always possible, and we usually don’t even know what overrides and workarounds third parties are using. Thus we expect some bug reports that need our help to determine who is actually responsible, and (if it’s a third party) whether WPF can or should adapt the behavior change to support the third party’s usage.