Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebView not displaying when applying AdditionalBrowserArguments #3704

Closed
RickStrahl opened this issue Aug 14, 2023 · 3 comments
Closed

WebView not displaying when applying AdditionalBrowserArguments #3704

RickStrahl opened this issue Aug 14, 2023 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@RickStrahl
Copy link

RickStrahl commented Aug 14, 2023

I'm trying to apply browser arguments to preview auto-play behavior for media elements in the browser using the --disable-features startup flag.

I'm using the code like the following:

// must create a data folder if running out of a secured folder that can't write like Program Files
var browserFolder = Path.Combine(mmApp.Configuration.InternalCommonFolder, mmApp.Constants.WebViewEnvironmentFolderName);

var env = await CoreWebView2Environment.CreateAsync(
    userDataFolder: browserFolder, options:   new CoreWebView2EnvironmentOptions
    {
        AdditionalBrowserArguments = "--disable-features=\"PreloadMediaEngagementData, MediaEngagementBypassAutoplayPolicies\"", 
    }
);
await WebBrowser.EnsureCoreWebView2Async(env);

When I use this (or several other startup flags I've tried, my WebView control fails to initialize and I get a blank WebView canvas - the browser appears to not load. I also don't get an error or a trigger in the BrowserProcessFailed event.

I'm not sure whether I'm using the Arguments option correctly and haven't been able to dig up any examples.

Expected behavior

  • Should work 😄

  • If it fails should throw or have some indiciation on what failed

  • WebView Control WPF (1.0.1901.177

  • .NET 7.0

  • Windows 11

@RickStrahl RickStrahl added the bug Something isn't working label Aug 14, 2023
@aluhrs13
Copy link
Contributor

Are you listening to CoreWebView2InitializationCompleted (https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.wpf.webview2.corewebview2initializationcompleted?view=webview2-dotnet-1.0.1901.177#microsoft-web-webview2-wpf-webview2-corewebview2initializationcompleted) at all? If there's a failure during initialization that's where it would show up.

If I had to guess based off what you've shared - Do you have a WebView2 already created with that userDataFolder, but with different AdditionalBrowserArguments?

@RickStrahl
Copy link
Author

Do you have a WebView2 already created with that userDataFolder, but with different AdditionalBrowserArguments?

Yes. It's in Markdown Monster and it's the previewer which gets loaded after the editor both of which use a WebView (multiples).

Do they all have to be exactly the same? I thought that each instance is starting a new process...

I'll check into thte initialization event and see if I get more info.

@aluhrs13
Copy link
Contributor

That's likely the problem, you'd see an initialization error of 0x8007139F (ERROR_INVALID_STATE) if that's the case. The table at the bottom of the docs for EnsureCoreWebView2Async mentions it.

As far as processes - Each WV2 creates a new renderer process, each UserDataFolder (UDF) creates a new browser process and AdditionalBrowserArguments essentially sets global state for the browser process. Every WV2 created with that UDF needs to have the same EnvironmentOptions / CreationProperties or it will fail. We chose to fail in this case since the AdditionalBrowserArguments can't/won't be respected due to the process already existing.

There is confusion around it sometimes and it's not perfect for every use-case - For your use-case, what would your preferred behavior be if we can't respect your EnvironmentOptions due to a conflict with existing processes? Some suggestions we've seen in the past include a setting to ignore the options if they differ, automatical create a new UDF (#3668), or somehow attempt to restart all the WV2s for the UDF.

@oggy22 oggy22 closed this as not planned Won't fix, can't repro, duplicate, stale Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants