actions
Update WebView2 Runtime / Align with Microsoft Edge version
Description
The WebView2 runtime version which is shipped in the Windows22 runner image is outdated and not aligned with the Microsoft Edge version.
Platforms affected
- [ ] Azure DevOps
- [X] GitHub Actions - Standard Runners
- [ ] GitHub Actions - Larger Runners
Runner images affected
- [ ] Ubuntu 20.04
- [ ] Ubuntu 22.04
- [ ] macOS 11
- [ ] macOS 12
- [ ] macOS 13
- [ ] macOS 13 Arm64
- [ ] macOS 14
- [ ] macOS 14 Arm64
- [ ] Windows Server 2019
- [X] Windows Server 2022
Image version and build link
20240317.1.0
Is it regression?
looks like?
Expected behavior
WebView2 Runtime version is aligned with the Microsoft Edge version: https://github.com/actions/runner-images/releases/tag/win22%2F20240310.1
Actual behavior
It's version 119 vs version 122 (stable).
Repro steps
I'm doing it like this: https://github.com/microsoft/playwright/pull/30009/files
There seems no trivial way of getting the runtime version, I'm connecting with CDP to the WebView2 window, opening Chrome DevTools of a simple WebView2 Application should also work and get the User-Agent there via navigator.userAgent.
Workaround - Update manually via official bootstrapper.
Invoke-WebRequest -Uri 'https://go.microsoft.com/fwlink/p/?LinkId=2124703' -OutFile 'setup.exe'
Start-Process -FilePath setup.exe -Verb RunAs -Wait
Duplicate of #9537
No, this is not a duplicate. What I have reported is independent of the installed WebView2 runtime, i.e. it happens even when I install the latest WebView2 runtime.
There seems no trivial way of getting the runtime version, I'm connecting with CDP to the WebView2 window, opening Chrome DevTools of a simple WebView2 Application should also work and get the User-Agent there via
navigator.userAgent.
For the system-installed runtime:
HKEY_CURRENT_USER\Software\Microsoft\EdgeWebView\BLBeacon@version
But this doesn't work when the application uses a fixed-version runtime.
Hence I'm doing it by starting from the application's window handle, then get the process id from the hWnd and with the process id, you can find the webview child process, which gives the executable path. From that you get the file version which equals the Edge version. Not sure whether that's better or worse than your approach ;-)
We do not ship a separate version of WebView2 and as far as I remember WebView2 itself comes as a part of the edge installation (which in turn as a part of the standard windows datacenter sku), if my mind does not lie it does not seem like a problem that should be solved in the scope of windows runner image
The runtime is included in the app package which is one of the officially supported distribution modes, named "Fixed Runtime Distribution Mode". This allows you to have your app always running with the same version, no matter what's installed somewhere.
Please see here: https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution#the-fixed-version-runtime-distribution-mode
The question is: why does it work everywhere else but not on the runner image? That's why I'm posting it here. Since it's not possible to get access to an actual running image, it's hard to troubleshoot, and the WebView2 team would have the exact same problem. I'm struggling with this for 3 days and nights now. I also have a UWP app which doesn't run there with WinAppDriver - but again it does on other machines.
It's ultimately hard to troubleshoot when you can't get hands on and run some tools to find out what's going on...
I have also run into this issue. I am trying automated UI test for a Tauri app which utilizes systems WebView2.
It's reporting Microsoft Edge WebDriver 122.0.2365.106 however the app is reporting Current browser version is 119.0.2151.58.
I assume these version should be aligned by the hosted image because you apply regular system updates.
Hey there!
I did a little research and found out the following:
- we do not install WebView2 and do not configure this component during the build process;
- WebView2 is a relatively independent component and is not automatically updated with the browser driver;
- the version of the component presented on the agent matches the version of the component that comes with the base image from the Azure gallery.
What's the result? Due to the distribution model of WebView2 which assumes either complete independence from the preinstalled version, or manual control, runtime installation simplicity - it takes only about 2 minutes to install desired version and maintenance concern, we would not want to include the installation of this component in the image build process.
So, due to this I'm going to close this item.
What's the result? Due to the distribution model of WebView2 which assumes either complete independence from the preinstalled version, or manual control, runtime installation simplicity - it takes only about 2 minutes to install desired version and maintenance concern, we would not want to include the installation of this component in the image build process.
So, due to this I'm going to close this item.
Your assessment is almost correct, but not in total: The WebView2 that is installed is the "Evergreen Distribution". This means that it is auto-updating. When the image would be running for a while, it would automatically update to the latest version. It's not possible to downgrade the evergreen version, it's system controlled. (that might not change your conclusion, though :-)
When the image would be running for a while, it would automatically update to the latest version. It's not possible to downgrade the evergreen version, it's system controlled. (that might not change your conclusion, though :-)
I didn't mentioned it because I wasn't sure about it. I didn't investigated WebView2 auto-updating mechanism, but almost sure that it's blocked in runners. Since we disabling almost all the base updaters like this:
# Disable Edge auto-updates
Rename-Item -Path "C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe" -NewName "Disabled_MicrosoftEdgeUpdate.exe" -ErrorAction Stop
I think disabling makes sense, because when you have some long running UI tests, it shouldn't happen that half of the tests use one version and the other one the newer version.
Regarding the absolute version, I don't think that any guarantees are needed about the installed version, because for once - when you ship an application that is relying on the evergreen distribution, it needs to be able to deal with whatever version a user has installed, and secondly, such tests will never be strictly reproducible, because you won't be able to keep the images at a specific version. These versions will always move forward and you cannot prevent that. If somebody requires reproducible behavior (like we do), one needs to ship the application with a fixed-version runtime of the WebView2 (like we do 😉).
BTW, if it's only about equality between an installed browser version and the WebView2 version, one could also install, Edge beta, dev or canary. In all those channels, the WebView2 is included with the browser. Only in case of the stable channel the two are separate.
@erik-bershel It seems like there's a regular update to the Microsoft Edge Driver - is there a way for the WebView2 RT to be updated to the same version at the same time?
Hey @victorhuangwq! We won't add separate WebView installation due to a maintenance reasons. The only available version is being provided by MS Edge.
The only available version is being provided by MS Edge.
May I ask if you could you clarify what you mean by this?
We won't add separate WebView installation due to a maintenance reasons.
Is this mainly because there's no way to update the WebView installation to a specific version to match the Edge Browser?
Thank you for the workaround. The downside is that this takes around 1min of time.
