Webview2 Runtime 114.* hangs on AddHostObjectToScript for already existing object

[pontusn]

Description
Clients automatically upgraded to 114.* hangs on startup when integration add COM object for script access where object by same name already exists.
Downgrading to fixed version 113.* makes client start properly. Removing existing object before adding it again also resolves issue.

Version
SDK: Latest, but seems to apply also to older.
Runtime: Release 114.*
Framework: Win32
OS: Win10, Win11

Repro

1. Call AddHostObjectToScript(L"test", ...)
2. Call AddHostObjectToScript(L"test", ...)

Workaround

1. Call AddHostObjectToScript(L"test", ...)
2. Call RemoveHostObjectFromScript(L"test")
3. Call AddHostObjectToScript(L"test", ...)

Technical Details
Our integration replace certain host objects in response to navigation. This scheme have worked flawlessly until WebView2 Runtime 114.*

Running from debugger we noticed that calls to AddHostObjectToScript hanged for second navigation, ie. when there already were objects with "conflicting" name. Removing the existing object before adding the replacement seems to work for all WebView2 Runtime versions we have available in our setup.

For our Windows client software this leaves us with two options:

• Switch to fixed version of WebView2 Runtime 113.*
• Release new build of the client that applies workaround

This is a matter of urgency for us since literally thousands of end-users are affected.

AB#44921645

[pontusn]

@champnic

[fwinkelbauer]

We are experiencing the same problem and have identified the same potential options/fixes:

• Downgrade to 113
• Add calls to RemoveHostObjectFromScript

We would highly appreciate an updated version of WebView2 in which calls to AddHostObjectToScript don't end up blocking our application. Otherwise we would need to update all our customers as soon as possible

[maxschaf]

Hi we are facing the same issue here with the same conclusion. We also have multi hundreds end users affected.

We are on our journey on fixing it with RemoveHostObjectFromScript. We are now cherry picking it to older versions and build agents will run hot today ....

super panic ;)

[M-Mommsen]

In our company downgrading was only a very temporary solution, because it did not take long and the update was back (sometimes only seconds, as if the installer was checking immediatly for updates). So only working solution was to try/catch "RemoveHostObjectFromScript" before every "AddHostObjectToScript", like pontusn already pointed out.

[gego1]

Hi
same for me.
Also having the same issue on our customer systems.
I could fix the issue by using RemoveHostObjectFromScript.

Gettin' a bit nervous because I need to deploy a hotfix to a lot of systems right now.
I don't know who will provide me all the required coffee for that action?!?!

Would highly appreciate a fix for this problem

Thx

[pontusn]

Fortunately our client offers two possible drop-in solutions:

• Replace DLL + loader to include fix
• Force fixed version of WebView2

Downgrading WebView2 in not possible unless you completely disable automatic upgrade.

[pontusn]

@david-risney

[frinkfree]

Would have been nice to have this information on Friday at 4pm (CST) when I was up 24 hours to isolate the issue and at the time the only solution was to move to a fixed version which was not straightforward at the time due to lack of coffee in the middle of the night.

[pontusn]

I was lucky to find the workaround within minutes after reproducing the issue in the debugger.

Simply pausing showed which call hung, but the puzzling twist was that it couldn't be every call that caused the issue.

A second runthrough revealed that replacing existing objects were the culpit. First thing I then tried was to remove any existing object before adding the replacement.

Ignoring any return value from removing non-existing objects completed the workaround.

That turned out to be the easy part. Distribution of the fix is far more difficult, especially when the automatic upgrade is triggered after the code that hung.

Currently we are attacking this with three different strategies depending on the end-user environment:

• PowerShell script that force the installed application into using fixed version 113.*
• Simplistic installer that inject new DLLs required by the fix, essentially extracted from new complete build of our client
• Complete upgrade to new build

The difficult part is when the end-user is neither local admin nor comfortable with running scripts.

[fwinkelbauer]

One of our customers found another workaround by setting the environment variable WEBVIEW2_BROWSER_EXECUTABLE_FOLDER to a local copy of Microsoft.WebView2.FixedVersionRuntime.113.0.1774.57.x64

[david-risney]

I've opened a tracking issue and will look into this now.

Has anyone tried using the latest Canary to see if the bug still exists in the latest builds? I'll try that in just a bit.

[ronnymgm]

This automatic upgrade caused hundreds of workstations running our POS with the WebView to freeze.
We are trying to have them back operational by releasing installers that use a local distribution copy with the fixed version 113.
MS team, ensuring quality and stable updates should be your highest priority!!

[david-risney]

FYI we've identified the underlying issue and are working on a fix.

[VivianDZ]

Is there an ETA on a fix for this?
We have way too many customers experiencing issues and re-installing our application for everyone is not being received well.

[pontusn]

Apparently the flawed build (WebView2 Runtime 114.0.1823.37) is still promoted via update channels. Holidays and lucky timing have mitigated the effect in Scandinavia. We expect to see full consequences on Wednesday morning when all offices open normal hours.

For corporate customers with controlled IT environment we currently advise them to stop automatic updates until either the workaround have been distributed or a fully functional build of WebView2 have been released.

[jensgustafsson]

Does anyone know if it’s possible to disable the webview2 version 114 update without disabling all automatic updates?

[lunac-catalyst]

We are currently encountering the same issues, many production users down. We have found older version installs but they all appear to be evergreen and as soon as the user reboots, they are upgraded to 114.* and break again,.
1.Do you have an older version that is fixed (not evergreen) for download that we can point our users to download?
2.I saw @david-risney was going to try Canary - any luck?
3.Also @david-risney said they found the issue -- any ETA on this -- this is a super critical issue - our application is used in financial transactions preventing people from making deposits into accounts.

[david-risney]

1. Regarding an older non-evergreen version without the bug, see https://developer.microsoft.com/en-us/microsoft-edge/webview2/#download-section. The Fixed Version v113 does not have this bug.
2. It is also broken in canary. The bug was introduced in v114.0.1822.0 and exists in all versions greater than that as well.
3. Yes I have found the issue and made a fix. The fix will show up in canary versions 116.0.1902.0 and greater (should be next canary release today/tomorrow). I'm working on porting it back to 115 (beta channel) and 114 (stable channel) now. I'll reply back to this thread with more info on ETA and exact versions of fix for 115 and 114 when I have it.

[pontusn]

Just noted that 114.0.1823.41 is now available for download. Does this update include the patch? Basic testing indicate that it is not included.

@david-risney @champnic

[david-risney]

The 114 fix is not yet released. I got the 114 fix in yesterday and it should be available in versions 114.0.1823.42 and higher. The current schedule has that getting released tomorrow. I will post back here if I find out any changes to the expected schedule.

[lcado97]

@david-risney Thank you for the information. Do you know when Microsoft will auto-push that release to workstations? You said you can download it tomorrow, but when will it auto push?

[champnic]

It should begin rollout/auto-push tomorrow as well, completing over the following 48-72 hours.

[lcado97]

Just to be clear, you are talking about canary only? Or are you talking about WebView2 also being auto-pushed over the next 48-72 hours?

[champnic]

I was only referring to the stable WebView2 Runtime version 114, which has a slower rollout to allow time to stop rollout if needed. Canary is pushed daily and should already have the fix available for testing in versions 116.0.1902.0+. I would expect that later today or tomorrow.

[pontusn]

Thanks for addressing this issue.

[champnic]

Canary build with 116.0.1903.0 has been rolled out with the fix for testing.

[david-risney]

WebView2 Runtime version 114.0.1823.43 containing the fix for this bug has been released and will auto-push completing over the following 48-72 hours like Nic described above.

[pontusn]

We have not yet received the automatic update, but was able to verify the fix via fixed version override.

Everything appears to be back to normal.

[lunac-catalyst]

WebView2 Runtime version 114.0.1823.43 containing the fix for this bug has been released and will auto-push completing over the following 48-72 hours like Nic described above.

2 of our 5 developers have received the update through normal channels and we have validated that it fixed our application for those two. Thanks for resolving the issue.

[champnic]

Rollout of 114.0.1823.43 stable WebView2 Runtime should now be complete. Thanks!