Open alxdg opened 3 years ago
I was able to get passed this issue, I noticed that the AllowsTransparency="True" on the main window was the reason why everything was transparent, but now I am seeing the resize border and I am not able to hide this. Any suggestions?
Hey @alxdg - thanks for the feedback!
In the screenshot you included, what is the WebView2 and what is the host app drawing? Is the WebView2 now displaying correctly when you changed the AllowsTransparency property?
I have experienced the exact same issue with a .NET Framework 4.7.2 application. I have had the opportunity to test on over a dozen machines. It works fine 90% of the time; the only machines that were failing contained “old or esoteric graphics hardware”:
2 machines with Intel Integrated Graphics from 2012 and an 8 output Matrox card (M9188).
Looks like those cards don’t handle transparency well. I tried turning off hardware acceleration but it made no difference RenderOptions.ProcessRenderMode = System.Windows.Interop.RenderMode.SoftwareOnly
;
Ditching the Window Transparency as described above fixed the issue but the same ugly bar appeared at the top.
Thanks for confirming the repro. I'll add this bug on our backlog to take a look.
I wanted to add that we're seeing the same behavior in our app. Setting AllowsTransparency
to true
on the window that hosts the WebView2 control stops some parts of the WebView2 showing. E.g. it will show popups, but not the page content.
This can be easily repro'd in a Windows virtual machine running on Hyper-V, every single VM I have tried exhibits this behavior.
We have a known issue we're working on where VMs trigger us to use software rendering, which was causing some problems that look very similar to this. I'll let you know when we have a fix and we'll verify this case as well. @bradp0721 FYI
@alxdg When you are deploying to other PCs are you using VMs?
When running VMs the result was always the same but in some instances of non VMs the problem persisted
@alxdg Sounds like it might be related then. On normal non-VM machines there are other cases that can trigger us to use software rendering, like specific graphics drivers, etc.
I can confirm that I have the same problem with normal computers with an integrated Intel graphics card (Like Intel Q45). On these computers I have to set the AllowTransparency
to false for the Webview to show up. On others computer with Nvidia graphic cards it shows up fine.
The only thing I don't understand is that my development computer doesn't have the problem even with an integrated Intel card (HD 520)
Same problem here. I have a demo based on the super-simple Getting Started app at https://docs.microsoft.com/en-us/microsoft-edge/webview2/ My reproduction of the problem is here. https://github.com/OllieJones/Webview2Win81Issue1118Demo
Everything works fine on Windows 10. I've tested it both on a physical machine and on a VM (VirtualBox).
On Windows 8.1 (VirtualBox VM based on modern.ie downloadable vms) the appearance of the website rendered in the WebView2 control is concealed behind the background color. Mouse events function normally though.
The workaround is obvious. Set the AllowTransparency attribute to False in this sample xaml.
<Window x:Class="Webview2Stripped.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:local="clr-namespace:Webview2Stripped"
xmlns:wv2="clr-namespace:Microsoft.Web.WebView2.Wpf;assembly=Microsoft.Web.WebView2.Wpf"
mc:Ignorable="d"
Title="MainWindow"
Height="450"
Width="800"
Top="300"
AllowsTransparency="True"
WindowStyle="None"
>
The problem also exists with an old modern.ie Windows 7 SP1 VirtualBox VM, for what it's worth.
I haven't tried it on any Windows Server releases.
And, just to make things wierder, on the offending systems when AllowsTransparency is false and Background is some color (like "red"), restoring the window from an iconized view paints over the rendered web site with the background. It's still there, it just can't be seen. Again, not a problem on W10, only on prior versions.
(We have lots of enterprise users dragging their feet migrating to Windows 10, so 8.1 is relevant to our business.)
@OllieJones I deployed your app on a modern.ie windows 8.1 virtualbox vm and it seems to load webview fine. I don't see the web content being obscured by the background color in any way. The only changes I made to the vm were downloading .NET runtime 478 and the webview2 runtime. Could you let me know if there are any other changes you made to your environment that I didn't? Also could you post a screenshot of the working/not working app so I know what to look for?
Just pinging this thread to see if anyone has any further info on a repro
I'm facing same problem at .NET 4.6.2 with Windows 7/8.1. I need a WPF with AllowTransparency=True
enabled, but then the webview content becomes invisible.
I'm facing same problem at .NET 4.5.0 with Windows 7, when set AllowTransparency=True
, webview content is "transparent" either, but the buttons in webview works fine (can be clicked) 🙃.
Facing the same problem, but without a workaround. AllowTransparency=False
will not fix it. Occurs even on my developer machine (Windows 10; latest WebView2 version installed; tested with several sample apps from https://docs.microsoft.com/en-us/microsoft-edge/webview2/code-samples-links). If this is a graphics driver issue, then this is the only piece of software that has problems with my graphics driver - I have never encountered such issue with any other software.
Is there a projected fix date?
We are currently evaluating a replacement for the IE WebBrowser in order to be ready for Windows 11, and WebView2 would have been the natural choice. Of course, this issue is a showstopper. We cannot run the risk to have the control fail like this on certain customer machines.
@tfunky Could you provide what UI framework you are using, SDK version (looks like 1.0.1083-prerelease?), runtime version, OS version (looks like latest Win10), and the contents of "edge://gpu" on the machines where you are seeing this? Are you seeing this on every device or only on your dev box?
We haven't been able to repro this issue on our machines and so haven't been able to debug into the underlying cause yet.
@champnic I tried the UWP (https://docs.microsoft.com/en-us/microsoft-edge/webview2/get-started/winui2) and WPF (https://docs.microsoft.com/en-us/microsoft-edge/webview2/get-started/wpf) samples.
In the course of trying to get this to work I modified the code to use AllowsTransparency=False and added a few event hooks (e.g. EnsureCoreWebView2Async(), CoreWebView2InitializationCompleted, NavigationCompleted). None made a difference, and all the indicators returned success. The page loaded for sure, because I could hover over controls to change the mouse cursor and click them. One of my test sites was bing.com, in whose (invisible) searchbox I entered some text; one of the links brought up a separate window which appeared like a ghost on my screen with a faint frame. (The standalone Edge browser works just fine, though.)
At this point I have played only with two machines: My dev box where the problem appears, and one other machine where it all works fine.
I tried SDKs 1.0.1056-prerelease and 1.0.1083-prerelease. For the runtime I tried MicrosoftEdgeSetupDev, MicrosoftEdgeWebview2Setup, MicrosoftEdgeWebView2RuntimeInstallerX86, MicrosoftEdgeWebView2RuntimeInstallerX64, Microsoft.WebView2.FixedVersionRuntime.95.0.1020.53.x64, all with product version 1.3.153.3. Contents of edge://gpu, see edge_gpu.txt
If you need someone to try some diagnostic or debugging experiments, I am willing to help out and spend some time on this.
Thanks for the info! I'm forwarding this on to our graphics folks to take a quick look.
Hey @tfunky - it looks like that edge_gpu.txt
was taken from the Edge browser (which makes sense because the WebView2 is invisible). Would you be able to do the same in WebView2 though? You should be able to use our Win32 WebView2APISample app, or even if the content is invisible you should be able to click in the WebView2 and do a "ctrl + A" (select all) and "ctrl + C" (copy) to get the info.
@champnic Here you go. embedded_edge_gpu.txt
Thanks! We're going to try and use this to repro the issue locally.
I noticed that this is also happening when building the WPF Sample with:
<Window
...
AllowsTransparency="True"
WindowStyle="None"
>
...
in Visual Studio 2019 and then adapt the executable to run in Windows 7 Compatibility Mode
.
@champnic maybe your devs prefer that rather having to set up a Windows 7 dev machine ;)
@tfunky Would you be able to capture a trace? When you do you can send it to me at champnic@microsoft.com
and may need to use a cloud sharing service, as the trace can sometimes be large.
To Take a trace:
--gpu-startup-dialog
to WebView2 browser args. This will pause the GPU process when it launches, and also give you the PID for the GPU process. Don't click 'OK' or close the dialog yet.tttracer -out <directory> -attach <GPU Pid>
Let me know if you need help running these instructions. Thanks!
I faced the same problem today, it looks like it's a graphic card driver issue, however the System.Windows.Forms.WebBrowser
control based on the Internet Explorer
works fine which means there's something wrong on the WebView2
, hope they fix it soon.
P.S. Setting AllowTransparency
to false did NOT solve the problem.
@rafak360 The problem is indeed certain buggy GPU drivers that the WebView2 control refuses to work with. You may want to try this workaround provided by Microsoft. It fixed the issue for me.
Add these browser arguments when initializing the WebView2: --ignore-gpu-blocklist --disable-gpu-driver-bug-workarounds
In C# the browser initialization will look like this.
WebBrowser = new WebView2();
var options = new CoreWebView2EnvironmentOptions("--disable-gpu-driver-bug-workarounds --ignore-gpu-blocklist");
var env = await CoreWebView2Environment.CreateAsync(null, userDataFolder, options);
await WebBrowser.EnsureCoreWebView2Async(env);
@rafak360 The problem is indeed certain buggy GPU drivers that the WebView2 control refuses to work with. You may want to try this workaround provided by Microsoft. It fixed the issue for me.
Add these browser arguments when initializing the WebView2: --ignore-gpu-blocklist --disable-gpu-driver-bug-workarounds
In C# the browser initialization will look like this.
WebBrowser = new WebView2();
var options = new CoreWebView2EnvironmentOptions("--disable-gpu-driver-bug-workarounds --ignore-gpu-blocklist");
var env = await CoreWebView2Environment.CreateAsync(null, userDataFolder, options);
await WebBrowser.EnsureCoreWebView2Async(env);
Thanks for the heads up @tfunky Is there any side effects on the workaround you provided? I mean will that decrease the gpu performance rendering web pages or something negative?
It shouldn't negatively impact performance, but you may hit other visual bugs on the affected drivers due to the bugs that were causing the drivers to disable DComp in the first place.
Having the same issues on a few Workstations where we use the Edge WebView2 inside one of our applications. (Nvidia) Driver update did not resolve this issue and the possible workarounds are not available (since it is the Harman AIR implementation, so currently no direct access to arguments)
@2jfw You can try setting the browser args using either environment variables or regkeys: https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2environment.createasync?view=webview2-dotnet-1.0.1293.44#remarks
Even if you aren't directly creating the WebView2, it should pickup those values when it does get initialized.
@2jfw You can try setting the browser args using either environment variables or regkeys: docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2environment.createasync?view=webview2-dotnet-1.0.1293.44#remarks
Even if you aren't directly creating the WebView2, it should pickup those values when it does get initialized.
Not 100% sure but do these environment variables look like they should work?
Regarding registry: I wasn't able to locate the folder "webview2" as it was mentioned in the link you provided "{Root}]\Software\Policies\Microsoft\Edge\WebView2\BrowserExecutableFolder "{AppId}"="" - there is only a folder named "EdgeWebView". How exactly would the registry item for "browserExecutableFolder" look like and what about the value of the {AppId}?
Those environment variables look correct. You'll have to make sure that the WebView2 in question is fully shutdown and recreated to pickup the new environment variable (typically just restart the app). For the registry key, you'll need to create the "WebView2" key and add the values in there. The "EdgeWebView" keys are related to the runtime installation I believe.
Note that both of these methods will affect all WebView2 controls for that user, so be sure to scope them to a particular app or remove them when completed (or leave them - it's likely the driver issue is affecting all of the WebView2 controls if that's the root cause).
I had the same problem and I solved it. The computer that occurred was formatted and no graphics driver was installed. Installing MicrosoftEdgeWebview2Setup solved the problem.
While I can see my webview in a window with AllowsTransparency = true
, I cannot interact with it anymore and clicks in the window go straight to the one below it.
The downside of using --ignore-gpu-blocklist --disable-gpu-driver-bug-workarounds
is that it doesn't really fix the root issue here. It simply allows using a GPU driver that would have otherwise been blocklisted by the Chromium GPU process (this is the rule that usually block the hardware rendering in Chromium on an Hyper-V Win10 VM). The rendering will still not work when the GPU process falls back to a software rendering backend (e.g. Swiftshader).
Here's more details about this bug:
--ignore-gpu-blocklist --disable-gpu-driver-bug-workarounds
flags make this less frequent by letting Chromium use some otherwise blocklisted GPU drivers, but it doesn't really fix the root issue here.--ignore-gpu-blocklist --disable-gpu-driver-bug-workarounds --disable_direct_composition=1
then the tabs won't render even if it's using the hardware accelerated path. When direct composition is disabled the renderer will do a blitting operation to copy the tab texture into the hwnd that gets presented in the browser process (the WebView2 embedder).
Description I am running into an issue where the web view is rendering the contents of my page but nothing is getting displayed on the container, it shows the contents all transparent, this behavior is only happening on a fresh installation of Windows.
I looked for errors in the developer console, program execution logs and event manager and there are no error reported anywhere.
This error only happens after deploying the app to other PCs, during development everything looks correct when I am running the app from Visual Studio.
Version SDK: WebView 1.0.774.44 Runtime: Webview2 Fixed version 89.0.774.57 Framework: Webview1 OS: 10.0.19042 Build 19042
Screenshots There is really nothing to show here only comment is that I can see that the images are getting rendered since I can drag them by clicking around and moving my mouse while holding down the click.
AB#32422186