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

[Problem/Bug]: Webview 131.0.2903.48 control panel entry mysteriousely disappeared #4931

Open
orbitalfenestra opened this issue Nov 15, 2024 · 12 comments
Assignees
Labels
bug Something isn't working

Comments

@orbitalfenestra
Copy link

What happened?

Just updated Webview2 this morning and I noticed that the control panel entry has vanished. Impossible to uninstall it from the control panel.

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

131.0.2903.48

SDK Version

No response

Framework

Win32

Operating System

Windows 11

OS Version

24h2 (26100.2314)

Repro steps

Update webview2 to the latest version (I did with winget)

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Don't know

Last working version (if regression)

Previous version

@orbitalfenestra orbitalfenestra added the bug Something isn't working label Nov 15, 2024
@vbryh-msft
Copy link
Contributor

vbryh-msft commented Nov 15, 2024

Is your app able to pick it up? Could you please share installer logs?

@orbitalfenestra
Copy link
Author

EdgeFiles.txt
EdgeRegistryMachine.txt
EdgeRegistryUser.txt
MicrosoftEdgeUpdate (2).log
MicrosoftEdgeUpdate.log
msedge_installer.log

Hope it can help!

Steps to reproduce:

From webview2 130.0.2849.80 do a winget update
Once at 131.xx.xx.xx.... entry in control panel is gone.

before
after

@orbitalfenestra
Copy link
Author

For some reason on one of my machines (not all of them), I realised that also Edge has vanished from control panel. I had to go tweak the registry to make it visible again. That trick doesn't seem to work with Webview2 tho.

@ajtruckle
Copy link

Is your app able to pick it up? Could you please share installer logs?

You should tag this on my ticket where the issue of installer logs was raised.

@asjimene
Copy link

asjimene commented Nov 15, 2024

I can confirm this issue, when attempting to install WebView2 silently (using /silent /install), the ARP registry keys are not populated. Logs and a screenshot of the ARP registry key are included.
EdgeFiles.txt
EdgeRegistryMachine.txt
MicrosoftEdgeUpdate.log
msedge_installer.log
RemoteDesktopManager_oFGSS8FCFL

@orbitalfenestra
Copy link
Author

I use this key as a SCCM detection. That's how I noticed. All softwares that require Webview2 will fail unless I change my detection method. I guess the best would be to wait to deploy this version everywhere?

@crian
Copy link

crian commented Nov 16, 2024

I have the same problem. After the webview update, it no longer appears in the windows settings -> apps. Reinstalling webview doesn't solve the problem either.

@aluhrs13
Copy link
Contributor

Assuming WV2 is still working and the only delta is the visibility of installation, yes this is intentional - https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel#announcement

@orbitalfenestra - For your SCCM purposes, we have our recommended installation detection method here - https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution?tabs=dotnetcsharp#detect-if-a-webview2-runtime-is-already-installed . Let me know if that doesn't work for your use-case.

@asjimene
Copy link

I'm sorry, why remove the Display name though? The proper, standard way of hiding an application from Add/Remove Programs is to set the SystemComponent registry value. This would prevent a breaking change for users and systems administrators while achieving the same effect.

https://learn.microsoft.com/en-us/windows/win32/msi/arpsystemcomponent

http://www.itninja.com/question/hide-in-add-remove-programs

This not only breaks standard detection methods, it also needlessly complicates software inventory collected by ConfigMgr and Intune for this application. I ask that you please reconsider this change and move to adding the SystemComponent registry value instead.

@MDawg957
Copy link

MDawg957 commented Nov 16, 2024

Assuming WV2 is still working and the only delta is the visibility of installation, yes this is intentional - https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel#announcement

@orbitalfenestra - For your SCCM purposes, we have our recommended installation detection method here - https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution?tabs=dotnetcsharp#detect-if-a-webview2-runtime-is-already-installed . Let me know if that doesn't work for your use-case.

I was using the Installed Software.Product Name in MECM to create a collection based on the app. That's cut off and this alternate detection method is terrible for that. Is there some reason you can't just use the SystemComponent value that @asjimene references? It seems like the better option and wouldn't break everything like this non-standard change does.

@orbitalfenestra
Copy link
Author

If it is the case, then will there be some kind of auto-update (like Edge) in SCCM possible ?

@aluhrs13
Copy link
Contributor

Thanks for the feedback and details. We've paused the rollout of 131 at 5% and are revisiting our implementation to see if we missed this scenario.

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

8 participants