[WPF .NET Core 3 XamlHost] NavigationView's drag&drop doesn't work correctly if display scaling isn't 100%

[ChuckBohling]

Describe the bug

I have a WPF app that's using a Xaml Island to host a UWP NavigationView. The MainWindow.xaml looks like:

<Window x:Class="WpfApp1.MainWindow"
...
<xamlHost:WindowsXamlHost x:Name="NavigationView" Loaded="NavigationView_Loaded" InitialTypeName="Windows.UI.Xaml.Controls.NavigationView"/>
...

NavigationViewItem's are programmatically created and added to the NavigationView. Each of the NavigationViewItem's have drag and drop enabled. If display scaling is 100%, everything works ok. But if scaling is not 100%, there are problems. What happens is that as an object is dragged over a menu item, the item it's over is not highlighted but one that's positioned below it is. If the drop is done, the handler for the highlighted item (the wrong one) is called.

I was able to hack my code and see that the positions sent to the handlers are not the same as the MainWindow coords. I believe they should be. If I multiplied the handler's received position by the scaling fraction, they match the MainWindow coords. Apparently, XamlHost is using the wrong coordinate system in this case.

I'm using .NET Core 3.1 with Microsoft.Toolkit.Wpf.UI.XamlHost 6.1.2. I tried with .NET Core 3.0 and an older version of XamlHost and had the same problem.

• Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:

Steps to Reproduce

You should be able to take any WPF app that has a Xaml Island NavigationView then for each NavigationViewIItem, set AllowDrop=true and define drag/drop handlers for it. Change the PC's display view to something other than 100% and do a drag and drop. You should see the problem.

Expected behavior

Obviously, the menu item I'm dragging over should be highlighted and a drop on the menu item should call its handler, not a different one.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

NuGet Package(s): 
Microsoft.Toolkit.Wpf.UI.Controls v6.1.2
Microsoft.Toolkit.Wpf.UI.XamlHost v6.1.2

Package Version(s): 

Project .NET Version:
- [ ] .NET Framework (version: )
- [ ] .NET Core 3
- [ ] .NET Core 3.1 Preview (version: )
- [*] .NET Core 3.1

Windows 10 Build Number:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [*] May 2019 Update (18362)
- [ ] Insider Build (build number: )

App min and target version:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [*] May 2019 Update (18362)
- [ ] Insider Build (xxxxx)

Device form factor:
- [*] Desktop
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio 
- [ ] 2017 (version: )
- [*] 2019 (version: ) 
- [ ] 2019 Preview (version: )

Additional context

Add any other context about the problem here.

[ghost]

Hello ChuckBohling, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[marb2000]

@ChuckBohling

Can you help me to understand the scenario? You said:

What happens is that as an object is dragged over a menu item, the item it's over is not highlighted but one that's positioned below it is. If the drop is done, the handler for the highlighted item (the wrong one) is called.

Does the dragged element come from the WPF and you drop into the XAML Islands?

[ChuckBohling]

Attached is a VS 2019 project you can use to see the problem. It's really simple. Just build it and run it in a window that's not 100% scaled. The larger the scaling, the easier it is to see the problem. When you do a drop, the title of the app is changed to the name of the menu item that the drop was sent to.

So for example, if you drag a file over "Item2", "Item3" will get highlighted and the drop will change the app's title to "Item3".

To answer your question, the dragged element comes from Explorer and is dropped onto the XAML Island NavigationViewItem.

NavViewDragDropBug.zip

[ChuckBohling]

@marb2000 Thanks for taking a look at this. If there's anything I can do to help, please let me know.

[marb2000]

Thanks @ChuckBohling I could repro it.

Repro steps:

1. Run the XAML Islands app in no 100% DPI monitor (e.g. 150% DPI)
2. Go to File Explorer and drag a file (it doesn't matter the file) over the Navigation View item. Eg. Item 1

• EXPECTED: The item 1 is hovered
• OBSERVED: The item 2 is hovered

3. Drop the file over a Navigation view item. The window title bar shows the item the drop was sent. E.g. Item1

• EXPECTED: The title bar shows Drop item1
• OBSERVED: The title bar shows Drop item3

@Austin-Lamb @ocalvo Is this a OS XAML known issue?

[ChuckBohling]

@marb2000 Any updates on this issue? File drag and drop is the primary input to our app so, with this problem, we can't release the product. Depending on if and when this gets fixed, I may have to redesign the UI, which I really don't want to do. So, any info will be welcome.

[marb2000]

@ChuckBohling, It seems that in Win32, the Drag&Drop APIs pass the physical pixels (as that's what Win32 usually works in), and XAML works in DIPs. So what it appears is that the points are over-compensated. Our first tests indicate that we need to multiply the points by RasterizationScale to get it to work, but our team is still investigating it.

If this is true, we can't fix the issue in the Windows 10 OS at this point; we can fix it only for WinUI 3 in Desktop apps and WinUI Islands (when available).

[ChuckBohling]

@marb2000 Thanks for the update. Well, that's unfortunate. For what it's worth, this problem does not exist with native UWP NavigationView. It's just with XamlHost. Does that make any difference?

[marb2000]

It's about how the underneath input layer is treated in the DesktopWindowXamlSource (DWXS) host. At a very high level, DWXS is "translating" Win32 input into UWP's CoreInput. There is not such a translation in UWP.

[zadjii-msft]

FWIW the upstream bug is microsoft/microsoft-ui-xaml#2101