Version 95.0.1020.30 causes CoreWebView2.Settings.UserAgent to intermittently fail

[joshmcorreia]

Description
After updating to Version 95.0.1020.30, the CoreWebView2.Settings.UserAgent property is intermittently failing. When accessing a webpage through WebView2 it sometimes uses the value that I set it to, and sometimes it ignores this value and acts as if it was never set. Previous versions always use the value that UserAgent is set to. No code in my product was changed.

Version
Runtime: Version 95.0.1020.30 64-bit
OS: Win10 (untested on others)

Repro Steps

1. Open software that uses WebView2
2. Right click on your webpage and click "Inspect"
3. Go to the "Network" tab and click the "Preserve log" checkbox
4. Click around on the webpage (being sure to click new links to generate new traffic)
5. Click on the network traffic requests and view the "User-Agent" Request Header (should be at the bottom of the "Headers" tab). Note that it changes between whatever you set it to and the default Request Header sent by WebView2.

AB#36914861

[champnic]

Hey @joshmcorreia - thanks for the bug report! Do you have an example log we can look at? Does there seem to be any pattern to the requests that use the old header?

[champnic]

I should also note that #1860 is due to browser policies getting incorrectly applied to WebView2 as well and is causing a bunch of undefined behavior. We have a fix in stable runtime 95.0.1020.38 which should be deployed in about a day. Please let me know if you still see the broken behavior after the update. Thanks!

[joshmcorreia]

There doesn't seem to be any pattern to the requests unfortunately. I just tried again on version Microsoft WebView2 95.0.1020.40 64-bit and the issue still persists.

[joshmcorreia]

Unfortunately I'm unable to provide network traffic logs due to the nature of the secure environment that I'm working in, but I'll keep an out eye to see if I can find consistency in the failures.

[champnic]

Thanks for confirming this isn't #1860. I've added this bug on our backlog.

[jarno9981]

@joshmcorreia try this works for me

private void newWeb_NavigationStarting(object sender, CoreWebView2NavigationStartingEventArgs e)
{

        if (new Uri(e.Uri).Host.Contains("accounts.google.com"))
        {
            if (newWeb.CoreWebView2 != null)
            {
                var settings = newWeb.CoreWebView2.Settings;
                if (settings.UserAgent != "Chrome")
                    originalUserAgent = settings.UserAgent;

                settings.UserAgent = "Chrome";
            }
        }
        else
        {
            if (newWeb.CoreWebView2 != null)
            {
                var settings = newWeb.CoreWebView2.Settings;
                if (settings.UserAgent == "Chrome")
                    settings.UserAgent = originalUserAgent;
            }
        }
        // Note: Oversimplified test. Need to support idn, case-insensitivity, etc.
      
     
      
    }

you can user !=null as trigger , you need to set original as string

string originalUserAgent = "";

[michaeltreynolds]

We are seeing this issue (or a similar issue). We have WebView2 version 99.0.1150.39. Our C++ app sets some settings and then begins a navigation. When I watch the requests in our telemetry and via fiddler I see that seemingly random ones do not have the new UserAgent. I see no consistent pattern on domain/method/sequence/etc.. The first request has the right user agent the next three do not. Then I get 14 that do, then 2 that do not. If I were to do some squinting it seems that requests with 302 redirects or the resulting requests from a 302 seem to drop the user agent more frequently than other types of requests. @champnic

We are curious what we should do. Although it seems hacky, one idea we had would be to redundantly check and set the user agent string on each navigation and on each request.

[champnic]

Thanks for the info! We have a set of issues we think are stemming from redirect failures and inconsistencies, so I'll add this one to investigate with those.

[yildirimcagri-msft]

Hi @joshmcorreia, we have root caused an issue that seems to be causing this. A workaround is to set the --disable-domain-action-user-agent-override browser argument in WebView2, please let us know if this works for you. Thanks!

[Kay-Burchardt]

Hi Microsoft,

we also experienced issues with the useragent in Webview2. Our embedding product - SAP Business Client - is patching the useragent to contain the term "SAP NetWeaverBusinessClient". We noticed that the patched useragent is not applied to frames that have a different origin than the root document. Additionally, we only receive the NavigationStarting and WebresourceRequested events for such frames. For frames that have the same origin as the root document we receive the full set of events, and the patched useragent is also applied!

@joshmcorreia I also tested your suggested "--disable-domain-action-user-agent-override" browser argument. Unfortunately, it didn't change the described behaviour.

Best regards,
Kay

Edit: Also tested with latest WebView2.1.0.1264.42 SDK and evergreen runtime. The issue still persists.

[yildirimcagri-msft]

I will look into this and get back to you. For the WebResourceRequested event not firing on out of process iframes, we have a fix in the works (from an initial guess the user agent issue could be related to this and may need a similar fix). For navigation events, which events are you subscribing to? Frame events should only come to FrameNavigation events (i.e. FrameNavigationStarting) or CoreWebview2Frame navigation events (i.e. CoreWebView2Frame.NavigationStarting).

[ghorowski]

Hi, I started getting this issue, altough I'm not sure if it's still related to WebView2 itself.
In PowerBI Desktop (January 2022) RS, I get this error since about a week or so:

When I click sign-in I can see a login window (empty but has ms office login link in the title) blink quickly and then I receive the above message.

The exact same thing is working fine PowerBI Deskop (from MS store) but I need to use the RS version.

I tried the following:

• completely reinstall PowerBI and WebView2
• fixes from the Cannot initialize with runtime 95.0.1020.30 #1860 but only the env variable part as BrowserSignIn policy on my PC was already set to 0 - I tried it with 1 and 2 as well

I have WebView2 v. 103.0.1264.62 installed

Update: I was able to fix it by upgrading PowerBI RS to May 2022 version but it's not a good fix for me since our report server is still on January 2022.

[champnic]

@ghorowski It sounds like there was a bug in PowerBI that got resolved between Jan and May releases. I'm not sure there's anything we can do on the WebView2 side for that issue. Thanks!

[Kay-Burchardt]

I will look into this and get back to you. For the WebResourceRequested event not firing on out of process iframes, we have a fix in the works (from an initial guess the user agent issue could be related to this and may need a similar fix). For navigation events, which events are you subscribing to? Frame events should only come to FrameNavigation events (i.e. FrameNavigationStarting) or CoreWebview2Frame navigation events (i.e. CoreWebView2Frame.NavigationStarting).

Currently we only register to FrameNavigationStarting. We are not using the new events of CoreWebview2Frame yet, so I don't know if they are working or not.
Additional observation: for frames of different domain, the WebResourceRequested event is only firing for the document, not for embedded resources like images or scripts. We also don't receive a corresponding WebResourceResponseReceived event for the document.

[yildirimcagri-msft]

Hi, lately I cannot repro this issue, could you provide some repro steps if this still happens for you?

[joshmcorreia]

Hi, lately I cannot repro this issue, could you provide some repro steps if this still happens for you?

I no longer work at the company that I worked at when I encountered this issue so I no longer have the code to reproduce. Feel free to close this since I can't confirm or deny.

[yildirimcagri-msft]

Closing for now, please reopen with repro steps if this issue persists.