Question regarding uses of APIs incompatible with `AppWindow` and `DesktopWindowXamlSource`

[lukeblevins]

How certain are we that erroneous uses of APIs incompatible with AppWindow and DesktopWindowXamlSource do not linger in platform XAML or WinUI?

As mentioned here, it is advisable for UWP developers to make their visual layer portable across the windowing hosts with XamlRoot.

I spent a considerable amount of time implementing AppWindow support for secondary views in a WinUI 2 UWP app only to find that hovering over elements in any MenuFlyout on the secondary views and quickly having the mouse pointer exit the flyout (or app) will block input to the entire application until I open the Start menu or ALT-TAB out of it. No exceptions anywhere to be found.

I have reason to believe this issue is present only when leveraging the UWP AppWindow, because it never occurred in the main ApplicationView.

Some more testing indicated that this problem only appears in the V2 styles and does NOT occur in platform XAML or with the v1 WinUI styles enabled.

I would love to contribute a fix for this, but it seems impossible to debug as the v1 and v2 styles look similar enough. Moreover, WinUI 3 is still closed source despite our continued feedback

Sample app
AppWindowBugRepro.zip

[lukeblevins]

FYI @chingucoding
and
@StephenLPeters (fixed a potentially similar issue found in TeachingTip: #6807)

[lukeblevins]

It seems like setting:
<x:Boolean x:Key="ThemeShadowIsUsingDropShadows">False</x:Boolean>
in App.xaml fixes the issue completely.

Going to investigate this some more with @chingucoding and I'll open a bug report here to reflect the new information.

[ojhad]

@bpulliam fyi

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.