MicrosoftEdge
[Problem/Bug]: window.chrome.webview.postMessage stops working on youtube.com
What happened?
window.chrome.webview.postMessage stops working when visiting pages on youtube.com. It accepts messages, but these messages never arrive on the native side, i.e., WebMessageReceived event. It works on any other site, e.g., wikipedia.org.
This seems to be caused by something that youtube.com has changed on their side, as it used to work with the same runtime version.
See our investigation results in my comment.
Importance
Important. My app's user experience is significantly compromised.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
135.0.3179.73
SDK Version
1.0.3116
Framework
WPF
Operating System
Windows 11
OS Version
26100.3775
Repro steps
Please use my WebView2Samples fork with the code to reproduce the issue.
- Change
BrowserExecutableFolder = "[path to WebView2 135.0.3179.73 runtime]"line inMainWindow.InitializeWebView()to point to the WebView2 135.0.3179.73 runtime directory. - Start the browser from the IDE and open the debug output window to see the
Debug.WriteLineoutput. - Visit https://www.wikipedia.org/ and observe
WebMessageReceived: {"Initial":true}followed byWebMessageReceived: {"Ping":true}every second. - Visit https://www.youtube.com/watch?v=vBCrJaLseQc and observe only a single
WebMessageReceived: {"Initial":true}message. Ping messages are not coming through. You can check the browser console to see that ping messages are still being sent from the JS side.
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
Regression
Don't know
Last working version (if regression)
No response
We think the root cause is the DocumentPolicyIncludeJSCallStacksInCrashReports origin trial that was active in Chromium M133-M135 (inclusive) and triggered by Origin-Trial header on youtube.com. As this trial is not active in M136, WebView2 versions 136.x do not exhibit this issue.
Similarly, passing --origin-trial-disabled-features=DocumentPolicyIncludeJSCallStacksInCrashReports to WebView2 135.0.3179.73 "fixes" the issue.
It is concerning that this origin trial is able to break WebView2 messaging. This indicates there is a bug in WebView2, including versions 136.x and beyond.
Hi @seldoff Apologies for the delay in response. Somehow we missed this. I happened to try this sample app with v135.0.3179.81 locally and I am able to reproduce the issue. Also tried the same in latest stable and dont hit this(v136) We will create a tracking bug and work on the same. Thanks for filing this !
@Badhri , the origin trial is now being rolled out as a feature in Chromium v137 (see https://chromestatus.com/feature/4731248572628992).
Do you have any information on whether the bug is caused by “Call stacks in crash reports from unresponsive web apps” feature, or from the presence of the origin trial (or presence of any origin trial)?
@Badhri, any news about this issue? We experience it again and were forced to use --origin-trial-disabled-features=DocumentPolicyIncludeJSCallStacksInCrashReports in our WV2 configuration to prevent messaging breakage.
Actually, this is not related to Youtube or DocumentPolicyIncludeJSCallStacksInCrashReports trial. E.g.:
- autotrader.com has the following active trials:
AIPromptAPIMultimodalInput,SoftNavigationHeuristics. If I disable onlySoftNavigationHeuristics, messaging starts working. I.e.SoftNavigationHeuristicsbreaks messaging, butAIPromptAPIMultimodalInputdoes not. - https://meet.google.com/xcj-pqkz-dpc has the following active trials:
AudioContextPlayoutStats,PermissionElement. Messaging starts working only when I disable both of them.
So messaging is broken when some trials are used, but not all of them.
@Badhri, considering this is a more widespread issue than initially assumed, can you please bump the internal priority of this issue?
The problem with "window.chrome" is that it's just a Javascript variable and it's very rare, but some scripts redefine it for themselves and after that it's no longer possible to make a request to Webview2. Perhaps you should use a more unique variable than "window.chrome"?
