WebView2Feedback icon indicating copy to clipboard operation
WebView2Feedback copied to clipboard

WebBrowser overlaps other controls in WPF?

Open sukesh-ak opened this issue 5 years ago • 66 comments

I am looking to display some WPF controls as overlay on top of web browser control. The moment you add webbrowser control, all other controls on the Page seize to exist.

Is this a bug or how the control will be in future too?

AB#25254665

sukesh-ak avatar Jul 25 '20 17:07 sukesh-ak

Maybe you need bring to front for these other controls i.e. Z-dimension?

oggy22 avatar Jul 25 '20 17:07 oggy22

Looks like it doesn't work. If I replace webbrowser control with any other control it works fine and shows behind the overlay. I guess Z index happens according to the order in which controls are defined in XAML.

sukesh-ak avatar Jul 25 '20 17:07 sukesh-ak

Bing has a WPF Map control , but Azure Maps does not have one.

The only way I saw is to use the webbrowser control for Azure Maps.

sukesh-ak avatar Jul 25 '20 17:07 sukesh-ak

So if Canvas.ZIndex doesnt work it is possible that it is a bug on our end. We will investigate. Thank you for reporting it!

Any chance you tried the same on Winforms?

oggy22 avatar Jul 25 '20 17:07 oggy22

There are discussions about this with the old Edge here and here

If nothing has changed from old Edge to new Edge on how the control is hosted in WinForms/WPF then its a terrible issue.

sukesh-ak avatar Jul 25 '20 18:07 sukesh-ak

@sukesh-ak unfortunately you have hit the well know airspace problem that appears to have the status at Microsoft of „will not fix“ and more recently as they yet again fake a WPF control by just using the winforms one — making the status for improving WPF to „we don’t care“. The only True WPF Control for a Webbrowser is called Cefsharp.

darbid avatar Jul 28 '20 17:07 darbid

@sukesh-ak unfortunately you have hit the well know airspace problem that appears to have the status at Microsoft of „will not fix“ and more recently as they yet again fake a WPF control by just using the winforms one — making the status for improving WPF to „we don’t care“. The only True WPF Control for a Webbrowser is called Cefsharp.

Will check Cefsharp. Thanks you.

sukesh-ak avatar Jul 28 '20 18:07 sukesh-ak

@darbid We're sorry you feel that way. Is there some indication you received that this was a "Won't Fix" issue for WebView2? Can you help me understand the difference between a "fake" WPF control and a "real" one? @sukesh-ak The airspace issue is currently being tracked on our backlog.

champnic avatar Jul 29 '20 00:07 champnic

Thanks @champnic Is there another issue I can subscribe to get notified when this issue is addressed?

sukesh-ak avatar Jul 29 '20 05:07 sukesh-ak

Oh @champnic I too feel your sorrows of the last 10 to 14 years on this issue. But as you asked the question I am happy to help. For the people landing here from a google search lets have a deeper dive into these sorrows;….and also give people more of an understanding of what they are getting themselves into before they spend too much effort on it.

Of course to answer your question this could be a highly technical answer which revolves around how WPF and win32 ("Windows") are displayed and also the issue known as Airspace. People can search for these on Google to get more info. I will also add some links as well.

For the people new here and who might implement this code hoping for a fix here is an analogy of Microsoft’s WPF webbrowser control history. You decide if they will fix it.

Imagine you wish to put up a picture on your thormo-insulated double brick wall. You call your handyman and he says we can put in a special fixture to the brick wall through the use of a drill to add a new function to your wall. That function being a hook. You then call the Microsoft Handyman because it is a big trusted company and ask him to add a picture to your wall. Microsoft gets out the saw and cuts a huge hole in your beautiful wall. They then put in a piece of iron sheeting with the hook attached to it. But so that it all looks good they dress up or disguise the iron to look like your wall by putting some brick wallpaper around it and fixing it to your existing wall very professionally. All good, right? Your picture is hung and it looks perfect. Not too long after cracks start appearing in your wall. The iron expands and contracts based on the temperature of the day differently to the brick wall, causing performance problems. Moisture also gets into the iron and rust stains start running down your wall. There is a problem. Now imagine that the Microsoft handman FIRST did this method of adding iron in 2006/7 and people complained for years about it. In 2012 the Microsoft handyman thought about fixing the problems but then decided not to. Then in 2015 or soon after the Microsoft handymen is asked again to hang a picture and they continue to cut a huge hole in the wall and put in iron. Then again in 2019 the Microsoft handymen had the opportunity to hang another picture differently, but again they cut a hole in the wall and put in iron. All along the Microsoft handymen knew the problems it causes but instead of doing something new they continued, knowing the problems, to do the same thing for over 10-14 years.

In order to bring this back to software. The first time Microsoft advertised a WPF webbrowser functionality was with the control known as the "webbrowser control" which i assume was around the beginning of WPF (not sure on the exact date but lets say 2006/7). This webbrowser control is simply the winforms control wrapped/disguised/faked (more about this word later too) as a WPF control. In 2012 Microsoft had a really good honest attempt in .net 4.5 beta to fix the problem, but never went through with it. Further Microsoft was asked soon after that in their uservoice (you know the place where they listen to users) to fix the issue in March 2012 and the request was declined without any reason. Strangely that post has been deleted by Microsoft (not intentionally of course) but I have added an image of the post. Notice the big red DECLINED.
Bring back the HwndHost IsRedirected and CompositionMode – Customer Feedback for Microsoft

So it is a matter of opinion but the words I would use is "Won't fix" but you make up your own mind. By the way to complete the software history, the original Microsoft Edge also was to get WPF browser functionality and it too was a wrapped/disguised/faked win32 window / winforms control, this was in or around 2015. And of course last year 2019 it was decided again to continue to implement the same problems with WebView2 as a result of Microsoft very strangely downing tools on years of Edge development and simply reusing the open source Chromium browser.

The use of the word fake. Lets first make it non-technical with an analogy;

Imagine a company took Hyundai cars from Korea and then replace the full interior and exterior parts of the car with Porsche. They then sit it in the car yard and call it a Porsche. It looks like a Porsche. All the “properties” you touch with your hands like the steering wheel and gear leaver/stick and door handles are all Porsche, right? Exposed to you the user is Porsche. Now drive it and honestly say it is a Porsche. Have a look under the hood? What would you call this?

The WPF Browser thing called Webview2 is exposed to the user with all the bells and whistles (functions and methods) of WPF. But look under the hood and it is a child window (aka old win 32 technology using a totally different method to display things) and thus when you use it, it performs like a Winforms control. In the words of one of the writers linked below “it is a black hole for your application”.

WPF sports some great performance features like resizing, rotation, skewing, changing opacity or visual brushes (all WPF features), but try them out on the WebView2 WPF thing. There is also another post here too on making the window transparent. You can forget it if WebView2 is on the window. And as the original poster pointed out try to add a WPF control (for lack of better word real WPF control) over the top of a WebView2 and nothing happens. This is because you cannot add WPF over the top of win32 ("Windows") thus I conclude that WebView2 is simply another control or child window dressed up/disguised or faked to look like WPF. But it is a matter of opinion and how dramatic you want to be. Maybe you could get your French or German PR colleagues to find a word and then use that. The leather industry had great success is selling fake leather as Faux leather. :-). MS could release the WPF Vortäuschte Autocomplete Textbox etc etc and WPF would flourish in new controls.

I love WPF. I can create some beautiful UI and as a kind of hobby programmer who creates small bits of software to help me at work I use it. I also use Microsoft technologies because I know that my colleagues who want to use my things can simply use it because they have a Microsoft operating system and all the dependencies etc are pre-installed. But please consider this. As of July 2020 WebView2 is not shipping to Win10 but it appears it will be installed with the installation of Edge Chromium browser. Given that Microsoft’s Browser popularity/usage is now in the single digits ie. less than 10% the advantage of knowing that my WPF application with a WebView2 control on it always works in a Microsoft Operating System is almost gone. If you are planning on using the Webview2 control in the future you will surely also have to get the user to first install the Microsoft Browser. Therefore this advantage has almost dried up and using 3rd party code like CEFSharp becomes more attractive. At least you know you have to install the dependencies.

I am really interested to hear your answer @champnic to the question "Is there another issue I can subscribe to get notified when this issue is addressed"? Where is the link @champnic :-). If there is not a link will you open one?

A few links on mixing WPF with Win32 and/or Airspace.

https://dzone.com/articles/wpf-45-%E2%80%93-part-8-solving https://stackoverflow.com/questions/9535167/has-airspace-support-definitely-been-dropped-in-wpf-4-5 https://docs.microsoft.com/en-us/archive/blogs/dwayneneed/mitigating-airspace-issues-in-wpf-applications

darbid avatar Jul 29 '20 08:07 darbid

Here is a practical example I was trying to find a solution for.

In the screenshot I am using a static image as a background which needs to be changed to Interactive map under the overlay visible at the bottom.

Since the backend is on Azure and I am using Azure Maps, there are no options to have the Map inside an App other than using Web-browser control in WPF/UWP.

This issue reported is a blocker for anyone trying to use Azure Maps in an application with a WPF/UWP control overlay (visible at the bottom) like in the screenshot below.

[image removed since I moved on]

sukesh-ak avatar Jul 29 '20 09:07 sukesh-ak

If you really still want to use the Webview2 it is impossible to have the bottom overlays as WPF controls on top. I think you have 2 options all with their own problems.

  1. make each of those overlays a wpf popup control. But this creates a whole lot of other problems.

  2. This is more of a hack, but in your XAML put your overlays in their right position UNDERNEATH your webview2. Then you need to subclass the Webveiw2 window, you will have to find the HWND. I think you listen for the WM_NCCALCSIZE message and then you "cut a hole" in your webview2 window so that your WPF controls show :-) To do this you use the WinApi to create a rectangle with CreateRectRgn, then you combine this rectangle with the win API CombineRgn and then SetWindowRgn. But this is truely a hack. It will make resizing slow and you will not be able to move your WPF controls. Also your beautiful opacity you use on the overlays are impossible. I have "cut a hole" in the WindowsFormsHost. You may find the WebView2 has been played with and does not pump messages the same as WindowsFormsHost and or Microsoft may make it difficult to find the correct windows handle to subclass. Thus I would suggest you try the WindowsFormsHost instead.

darbid avatar Jul 29 '20 09:07 darbid

@darbid Thanks for your time.

I tried the WPF popup control route and its messy. Thinking of ditching Azure Maps for now and also moving to UWP (for pen and other support options) which opens up better options to solve this issue.

  1. UWP Map control which uses Bing Maps (not sure if it supports GeoJson, yet to check)
  2. SyncFusion Maps control which supports multiple map providers and GeoJson support. They also have a community license which is good for me to start with for free.

I am guessing at some point in future, Bing maps will stop API support for applications and move to Azure Maps. If that happens it becomes another step to port again. So Syncfusion option becomes a better route for now..

sukesh-ak avatar Jul 29 '20 10:07 sukesh-ak

Thanks @sukesh-ak for the practical example, and thanks @darbid for the detailed write-up! I understand much more about where you're coming from now.

Perhaps we should market WebView2 as a "Genuine WPF Control", to continue borrowing from the leather industry :P https://bestleather.org/types-of-leather/genuine/

@sukesh-ak We are tracking this ask internally and have it linked to this GitHub issue. We will update this GitHub issue when the code is done, and close it with supported SDK/browser version numbers when it ships.

@darbid We are aware of the challenges with distribution of support for WebView2, and are weighing our options between inbox support from Edge, the runtime, and having to install the dependencies through an installer. Our ideal goal is to have WebView2 "just work" on Windows devices without needing extra steps (which you mentioned as a thing you love about .NET) but we're not sure that will be a feasible goal. We're pushing to get as close as possible though.

champnic avatar Jul 29 '20 18:07 champnic

Genuine Leather is a nice find. Respect. Genuine Porsche ? I don't think would fly.

Unfortunately I am not sure the software industry has such flexibility. At the end of the day the difference between win32 and WPF is in the way controls are rendered to the display. If the control displays each and every pixel through the use of win32 GDI methods and not with the assistance of WPF directX technology it is not a WPF control.

To be honest (and I am hope I am wrong) it looks like simple laziness or lack of love for WPF. Did the software engineers in the meeting on WebBrowser Control / WebView / Webview2 just say "Stuff it, lets save time, build one control, wrap that control in WPF and lets go play xBox"? :-) The really frustrating thing is that there is no work around for the control, there is no fix. This is evidenced in the efforts indicated in "Mitigating Airspace Issues In WPF Applications".

You are doing a great PR job but I'll bet you a beer that when Microsoft announces an End of Life of WPF this issue will still exist and the WPF control that houses a webbrowser will still have all the problems it has now. I hope I am wrong.

darbid avatar Jul 30 '20 06:07 darbid

Haha, Xbox is alluring!

I can assure you it's not laziness though - it's mostly the balancing of lots of different priorities (OS, devices, languages, frameworks, etc.) of which WPF is but one, and the airspace issue is but one (quite expensive) problem. It's a pretty fundamental problem though, and is relatively high priority for us. We know a fix is possible because CEF/CEFSharp has it working and we're built on similar internals (Chromium), but we're not sure if the fix is going to be too expensive or complex to maintain on top of a constantly shifting Chromium.

I hope you're wrong too 🤞

champnic avatar Jul 30 '20 17:07 champnic

The WebView/WebBrowser z-order issue is such a long-standing problem in our WPF application. We have to explain to users of our s/w why controls and other things do not show up properly with the embedded browser piece. We have hoped for years and years that this would be fixed with a new browser control. Please, please, please, please, please up the priority on the airspace problems. It is so shocking to me that this would be on a backlog and not a #1 or #2 priority for use.

jschroedl avatar Aug 14 '20 15:08 jschroedl

reading this post makes me sad. similar things can be said about the MediaElement control.

Just poor wrappers over tech that doesn't quite fit.

julesx avatar Nov 25 '20 12:11 julesx

#708

DineshSolanki avatar Dec 04 '20 04:12 DineshSolanki

I'm here, trying to figure out why my ScrollView always renders behind my WebView2. Looks like this is "expected," if not the desired eventual behavior. I wish that were different. Edit: Came back 20 minutes later, having switched over to Cef (which I've used before.) Still wish I could use WebView2, but for now, Cef is letting me put a control behind scrollbars.

Seeker9889 avatar Feb 02 '21 20:02 Seeker9889

@champnic

If you don't want to make an real 100% WPF control for webview, you have two possible workarounds:

  1. Use modified second WPF Window with some transparency and tracking of parent. Some like on my rusty repo: https://github.com/kolorowezworki/Airhack

  2. Make your original control render out of screen and transfer frame stream to WPF Image. This trick is common used in e.g. Opengl wrappers. You will still have to transfer back user input, so it can be a bit more difficult.

adamfierek avatar Apr 13 '21 04:04 adamfierek

Any update with this one?

gitmarcalinascris avatar Jun 14 '21 14:06 gitmarcalinascris

Are there any plans to fix this?

I'm currently in a situation where we had used CefSharp in our app because of the airspace issues with WebView2, but now we have a new business requirement to support playing MP4 videos embedded in HTML which isn't supported by CefSharp.

So now we are faced with needing to use both CefSharp and WebView2 for different use cases within the same app, which obviously complicates and bloats the code, greatly increases the size of deployments, etc...

jonathanmarston avatar Aug 18 '21 13:08 jonathanmarston

Any update on this 'Airspace' issue and how to override this issue?

schandra09net avatar Sep 15 '21 14:09 schandra09net

any updates or possible workarounds?

Sebbstar avatar Oct 07 '21 14:10 Sebbstar

Use cefsharp

julesx avatar Oct 07 '21 14:10 julesx

Use cefsharp

unfortunately this is no solution. We have to migrate from cefsharp because of security issues. We want to rely on windows updates to be able to receive security patches automatically 😒

Sebbstar avatar Oct 07 '21 14:10 Sebbstar

I hear you. Unfortunately it seems wpf support for core components initially designed for win forms are not on Microsoft’s radar at all. See MediaElement which has been in a bad state for a decade now. I wouldn’t expect much.

julesx avatar Oct 07 '21 15:10 julesx

None.

On Thu, Oct 7, 2021, 10:54 AM julesx @.***> wrote:

Use cefsharp

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MicrosoftEdge/WebView2Feedback/issues/356#issuecomment-937871833, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBFHNNCY46QFORMIESAWUDUFWYBPANCNFSM4PHRXN2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

ChrisHonsinger avatar Oct 07 '21 22:10 ChrisHonsinger

any updates or possible workarounds?

Just the second post above yours was telling you possible workarounds: https://github.com/MicrosoftEdge/WebView2Feedback/issues/356#issuecomment-901131757 and there won't be any official updates for this issue in the near future. It needs to get addressed by WPF, not MS Edge Team. And for this the WPF team has to do bigger code changes and only in case this can be fixed at all.

Symbai avatar Oct 08 '21 05:10 Symbai