search

MicrosoftEdge / WebView2Feedback

Feedback and discussions about Microsoft Edge WebView2
https://aka.ms/webview2
453 stars 55 forks source link

Webview on transparent WPF regions does not hittest. #997

Open Skarnivorous opened 3 years ago

Skarnivorous commented 3 years ago

Description When WPF window has Allow Transparency and no style (completely transparent window). And WebView2 is on window region where no other controls are visible (i.e. Panel hosting WebView2 are background transparent / opacity 0). And WebView2 content is visible (though it may have opacity). Clicks on WebView2 will pass through WebView2, not trigger webview2 content events, and activate desktop UI beneath the window.

Expectation would be that the WPF hit test takes into account WebView2's visible painted areas. Ideal would also treat non-painted areas as pass-through.

Version SDK: 1.0.790-prerelease Runtime: Version 90.0.809.0 Framework: WPF, C#, XAML OS: Windows 10 Pro Version 20H2 OS build 19042.804 Windows Feature Experience Pack 120.2212.551.0

Additional context With the new DefaultBackgroundColor allowing transparency I have successfully rendered WebView2 content in a transparent window with alpha blending/composition on the desktop. The bug above however means that there can be no interaction with the content as the entire control is not hittested even for the areas of the control which are visible.

Re-enabling window background, or having other wpf controls visible behind or in-front of the webview2 will suddenly make the webview2 receive hittest in the regions where the other controls overlap.

AB#31911566

darbid commented 3 years ago

Can you add an image of what you are talking about? Unfortunately your text is indicating something that is impossible for the webview2 as it is not a true wpf control but a wrapped winforms control and thus allows transparency in wpf will effect the webview2

Skarnivorous commented 3 years ago

I have linked a screen video to demonstrate. In the video the red box is the webview2 and the clock is a normal image control. You can see that when I click a region in the webview2 that overlaps the clock, the webview2 will receive the click event. However when I click a region in the webview2 that is only overlaying the desktop, the click will pass straight through. I believe the webview2 should still receive the hittest / mouse event as it is still visible. All WPF layer/visual tree type calls also ignore the webview2 in those areas. I would expect if the webview2 has 100% transparency in some region, then it should have this correct behaviour of click passthrough.

https://streamable.com/szltec

Skarnivorous commented 3 years ago

I am hoping this can be realised as possible via native implementation as I have succeeded using a workaround using CapturePreviewAsync running continuously but I imagine this is a slow routine.

pagoe-msft commented 3 years ago

@Skarnivorous

Thanks for submitting this - I've added this item to our backlog.

Blightbuster commented 1 year ago

I am hoping this can be realised as possible via native implementation as I have succeeded using a workaround using CapturePreviewAsync running continuously but I imagine this is a slow routine.

Would you mind sharing your workaround implementation? I assume you overwrote the HitTestCore method of the WPF WebView2 contol?

Skarnivorous commented 1 year ago

No, I took snapshots of the webview2 control content (which preserved transparency) and then used that as an image control source under the webview2. This made the image control the same hittest "shape" as the webview2 content so the webview2 then received the unser interaction only where there was visible content. It worked but the sample rate of the snapshots was so slow, the image control content and the webview2 content was out of sync by about 200-1000ms. I was working with animated webview2 content so this was not enough. If your webview2 content is fairly static, this may work for you.

On Fri, 6 Jan 2023, 07:55 Blightbuster, @.***> wrote:

I am hoping this can be realised as possible via native implementation as I have succeeded using a workaround using CapturePreviewAsync running continuously but I imagine this is a slow routine.

Would you mind sharing your workaround implementation? I assume you overwrote the HitTestCore method of the WPF WebView2 contol?

— Reply to this email directly, view it on GitHub https://github.com/MicrosoftEdge/WebView2Feedback/issues/997#issuecomment-1372735636, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFVCDGV64NIHTV6TUETW7P3WQ4YNPANCNFSM4YIUINEQ . You are receiving this because you were mentioned.Message ID: @.***>

xu-ms commented 1 year ago

@Skarnivorous I try to reproduce your scenario, I've also created an image and WebView control and set webView2Control.DefaultBackgroundColor = System.Drawing.Color.Transparent. It seems that when I click on the transparent area, it is still responded to by the WebView, and the text can be selected. Perhaps my understanding is incorrect; can you please explain further? Animation

Skarnivorous commented 1 year ago

Thanks for investigating! - the feedback / issue is that the usual behaviour of WPF/browser controls in this scenario is expected to pass the hit test / click through the transparent areas to the parent controls > parent app window > desktop app windows or desktop below the web view control.

And in cases where the webview control is not over a visible parent control, no click events on visible content are triggered, where it would be expected visible content click events should still trigger, and only transparent areas clicked should pass through.

I understand it may be the current behaviour of the control - but that it would be an improved behaviour to work in this manner, perhaps optionally.

Essentially, in these two scenarios, it's working the opposite to what might be expected. It's been a while since I testes these scenarios - I'll try them again and link to a demo git with step by step to reproduce.