Dragging a file from Explorer over top of a WebView2 in the application window will launch another process

jschick04 commented 4 months ago

Describe the bug

I am working on a project that is basically an alternative to the Event Viewer MMC snap-in where we load evtx files and parse and display those events. Recently, I have noticed that dragging and dropping a .evtx files onto the application window is now launching an additional application process. If go into settings and change the .evtx extension default handler back to the Event View MMC then dragging and dropping a file onto the window will launch the Event Viewer MMC snap-in.

There have been no code changes to how we handle OnDrop or OnDragging and I have not been able to pinpoint any specific change around when this issue started. If I install a previous version of the app before the issue started then it does not repro but if I roll back to the commit tied to that release then I can reproduce the issue again. I have also tested previous .NET SDK versions with no success.

My suspicion is that it may be tied to the fix for the following issue that was recently resolved but do not have any hard evidence against this right now. https://github.com/microsoft/microsoft-ui-xaml/issues/7366

I have been able to reproduce this issue on a clean MAUI Hybrid project in VS 17.9.

Initially filed this over on the Maui repo but was recommended to bring this issue over here. https://github.com/dotnet/maui/issues/22556

Steps to reproduce the bug

Create New Project > .NET MAUI Blazor Hybrid App

Add the following to MainPage.xaml inside BlazorWebView

<BlazorWebView.GestureRecognizers>
<DropGestureRecognizer AllowDrop="True" />
</BlazorWebView.GestureRecognizers>

Run the app and drag a file over the window and 2 ghost icons will show up Release the mouse button and the default application for the extension of the file being dragged will be launched. In the case of the above screen shot, dragging a .PML file over the window and releasing will launch procmon

Expected behavior

App should be able to handle this file via OnDrop and no other applications should be launched

Screenshots

No response

NuGet package version

None

Windows version

Windows 11 (22H2): Build 22621

Additional context

No response

github-actions[bot] commented 4 months ago

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you!

Closed similar issues:

Cannot drop files from Explorer into WebView2 in a WinUI3 app (#7366), similarity score: 0.78
Windows APP SDK 1.3230331000 Drag and Drop Crash still present (#8450), similarity score: 0.75
Preview2: Crash during drag & drop (0x00007FFBCFD8B362 KernelBase.dll) (#7002), similarity score: 0.73
Unable to drop files onto Grid in WinUI3 Desktop (#2715), similarity score: 0.73
Drag & Drop "Access Violation" when using Async Main (#7385), similarity score: 0.72

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

jschick04 commented 4 months ago

If it helps, it seems like it may be EmbeddedBrowserWebView!base::LaunchProcess that is making the call to CreateProcess that results in the default extension handler in windows launching based on the extension.

kernel32.dll!CreateProcessWStub
windows.storage.dll!CInvokeCreateProcessVerb::CallCreateProcess
EmbeddedBrowserWebView.dll!base::LaunchProcess
EmbeddedBrowserWebView.dll!embedded_browser_webview::internal::WebViewFactory::EnsureConnection
EmbeddedBrowserWebView.dll!embedded_browser_webview_current::EmbeddedBrowserWebView::CreateWebViewOnIOThread
<snip>

jschick04 commented 3 months ago

Looks like this is the last version that doesn't reproduce the issue

<PackageReference Include="Microsoft.Maui.Controls" Version="8.0.14" />
<PackageReference Include="Microsoft.Maui.Controls.Compatibility" Version="8.0.14" />
<PackageReference Include="Microsoft.AspNetCore.Components.WebView.Maui" Version="8.0.14" />

jschick04 commented 3 months ago

Curious as to why this regression is being closed as not planned? This is a major accessibility feature for our app that is widely used by CSS and not fixing this regression will result in us being unable to update to latest WebView.

ranjeshj commented 3 months ago

@jschick04 apologies. I mistook your last comment that this was fixed in the last release. Could you provide a simple repro project for this in WinUI3 if possible (not MAUI) ?. EmbeddedBrowserWebview.dll is not part of WinUI. Let me follow up to find more.

jschick04 commented 3 months ago

I will see if I can repro this with a WinUI project.

My app and the repro provided above was done with Maui hybrid and I initially opened an issue with Maui and was directed to this repro (issue linked in the first comment).

jschick04 commented 3 months ago

Ok, I was able to reproduce the issue by creating a WinUI3 project and adding the following to MainWindow.xaml

<WebView2 x:Name="webView" AllowDrop="True" DragOver="OnDragOver" Drop="OnDrop"></WebView2>

Inside of MainWindow.xaml.cs I replace MainWindow constructor with the following and add the OnDragOver function to allow the copy operation.

public MainWindow()
{
    InitializeComponent();

    webView.Source = new Uri("https://www.bing.com");
}

private void OnDragOver(object sender, DragEventArgs e)
{
    e.AcceptedOperation = DataPackageOperation.Copy;
}

private void OnDrop(object sender, DragEventArgs e) { }

Running the application will show the double icons as shown in the initial post. This scenario doesn't launch the default extension handler but will launch a separate window with a prompt to download the file that I drag over the application.

ranjeshj commented 3 months ago

There is an API to intercept the new window creation – have you tried using that to see if you can achieve the experience you want? The code below works for me. It automatically downloads the file without asking for consent, but I assume that can be added in the code below if needed.

webView.CoreWebView2.NewWindowRequested += CoreWebView2_NewWindowRequested;

private void CoreWebView2_NewWindowRequested(Microsoft.Web.WebView2.Core.CoreWebView2 sender, Microsoft.Web.WebView2.Core.CoreWebView2NewWindowRequestedEventArgs args)
{
    args.Handled = true;
    this.webView.Source = new Uri(args.Uri);
}

jschick04 commented 3 months ago

Using the NewWindowRequested callback and just setting args.Handled = true prevents the new window but still shows the double icon. I can probably work around this by just disabling the icon and text from the XAML side.

I will need to see how I can adapt this to Maui Hybrid to see if it works around the issue there and to see how this interacts with the addition of the drag handlers on the web side of things. This was another issue that I ran into is the WebView2 drag/drop functionality did not play well with Blazor Hybrid but that is another issue for when we can go back to using the most recent version of WebView2.

Ideally it seems that WebView2 should respect the drag/drop handlers from the XAML side or XAML should defer to WebView2 if that is where the drag/drop functionality is going to have to be configured. Or maybe a global option to configure XAML or WebView2 as the default handler for drag/drop, especially since it looks like the addition of drag/drop functionality from WebView2 is where this all started.

jschick04 commented 2 months ago

Looks like this workaround isn't viable for Maui or at least I cannot find the NewWindowRequested callback for how this is implemented with Maui Hybrid.

microsoft / microsoft-ui-xaml