Open nirdil opened 2 months ago
I have the same problem. Here is a sample code (omitted XAML / WinUI 3).
using Microsoft.UI.Xaml;
using Microsoft.Windows.AppLifecycle;
using System;
using System.Diagnostics;
using System.Threading;
namespace Sample {
public partial class App: Application {
private Window? window;
public App() {
InitializeComponent();
}
protected override async void OnLaunched(LaunchActivatedEventArgs args) {
var main = AppInstance.FindOrRegisterForKey("main");
if (main.IsCurrent) {
window = new MainWindow {};
window.Activate();
// some heavy process.
Thread.Sleep(2000);
} else {
await main.RedirectActivationToAsync(AppInstance.GetCurrent().GetActivatedEventArgs());
try {
Process.GetCurrentProcess().Kill();
} catch {
}
}
}
}
public sealed partial class MainWindow: Window {
public MainWindow() {
InitializeComponent();
InitializeWebView();
}
private async void InitializeWebView() {
await WebView.EnsureCoreWebView2Async();
WebView.Source = new("https://example.com/");
}
}
}
https://github.com/user-attachments/assets/0d2cb713-c0b7-4a71-af64-35481c22447c
Thanks for opening this - I've added it as a bug on our side and we'll take a look right away. It's a good sign that it seems to be resolved in newer runtimes.
@naoki-yamamoto-ymh Are you able to see the issue in newer prerelease runtimes, like the current Dev channel? https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/set-preview-channel?tabs=api#downloading-the-prerelease-sdk-and-a-preview-channel
@champnic Thank you for your reply. I confirmed that this issue is resolved with Dev (130.0.2849.1) version!
Hi @champnic - We have the same issue with Maui Blazor Windows.
Is there a way for us to test this with a newer version as well? Maui references Windows App SDK (1.6) - not sure how to switch to a later WebView2?
Thanks!
I just got a report that this issue is also affecting WebView4Delphi developers.
We are seeing this issue in our Win App SDK 1.4 and 1.6 based applications in already installed applications. It started showing up around 3-4 days ago. I'm guessing there was an update to the edge browser that started to cause this behavior.
@champnic Thank you for your reply. I confirmed that this issue is resolved with Dev (130.0.2849.1) version!
Thanks for confirming! 130 stable runtime should be deploying around mid-October.
Is there a way for us to test this with a newer version as well? Maui references Windows App SDK (1.6) - not sure how to switch to a later WebView2?
https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/set-preview-channel?tabs=api#downloading-the-prerelease-sdk-and-a-preview-channel You'll need to download a prerelease channel of the Edge browser (Canary or Dev), and then switch the runtime search order. Using the registry key or environment variable are probably the easiest here: https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/set-preview-channel?tabs=registry-key#switching-the-channel-search-order-recommended
https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/set-preview-channel?tabs=api#downloading-the-prerelease-sdk-and-a-preview-channel You'll need to download a prerelease channel of the Edge browser (Canary or Dev), and then switch the runtime search order. Using the registry key or environment variable are probably the easiest here: https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/set-preview-channel?tabs=registry-key#switching-the-channel-search-order-recommended
This is working well with Maui Blazor Windows and Dev (130.0.2849.1) - adding in MauiProgram.CreateMauiApp() (or similar):
Environment.SetEnvironmentVariable("WEBVIEW2_CHANNEL_SEARCH_KIND", "1");
@champnic - Thanks for this! Would you know if by around mid-October there will also be a Windows App SDK update to go with the 130 stable runtime?
For a reasonable workaround, set the webview's initial window size and position via the browser arguments e.g.:
Environment.SetEnvironmentVariable("WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS", "--window-size=0,0 --window-position=20000,20000");
Place this close to your application start so that these arguments are set before the (first) webview is launched.
This is not perfect as a little bit of the window still pops in at the screen edge. But this way it is far less noticeable. Unfortunately, it is not possible to move the window fully outside of the view.
We have tested this with Maui Blazor but should work anywhere.
I'm experiencing the same issue in my UWP apps, and I've observed it in the WinUI 3 Gallery as well.
Runtime Channel - Stable release (WebView2 Runtime) Runtime Version - 129.0.2792.65 Operating System - Windows 11
I've attached a screen recording that had captured the flickering in my POC.
https://github.com/user-attachments/assets/53a15502-f60b-437a-a25e-e12a34c7b5f6
This bug is quite severe, as all our released products with embedded WebView2 have suddenly started exhibiting strange behavior. Do you know when the fixed version will be released? We've also found that the issue occurs in Visual DirectComposition Mode, but not in Windowed Mode.
As a serious product, this kind of bug is really BS. It affects billions of people.
I updated the bug as I see now it's happening everywhere, and on each newly created WebView. I also have a feeling the WebView initialization time got deteriorated together with this glitch, but have not accurately tested it yet.
@nirdil When you say "anywhere", you mean on frameworks outside of WinUI2/UWP? And it's still fixed when using a newer runtime?
@champnic If you look above this bug was also flagged in a Delphi implementation, so it's a fairly safe to assume that this is happening outside of the Windows App SDK/WinUI3 and UWP/Winui2 frameworks.
@champnic everywhere - in every framework, and yes it's still fixed in edge dev runtime.
What happened?
When initializing any WebView, a blank window briefly appears before disappearing. This is most noticeable on app startup where the window can appear for a few seconds, but it is also noticeable sometimes very briefly on any new WebView initialization.
This seems to be a relatively recent bug that was introduced to the production Edge channel.
Additionally, this issue does not occur in the Edge Dev channel, which suggests it has been resolved in a later version. I’m unsure if this is a documented bug.
Can anyone confirm which version includes this fix and when it will be available in the production channel?
Importance
Important. My app's user experience is significantly compromised.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
129.0.2792.52
SDK Version
1.0.2839
Framework
WinUI2/UWP
Operating System
Windows 10
OS Version
10.0.19045
Repro steps
Not reproducible on a small sample project
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
Regression
Regression in newer Runtime
Last working version (if regression)
No response
AB#54137238