Open romanan opened 3 years ago
QT support has indicated this needs to be addressed on the Chromium side and they have logged this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1202023
Thanks for the report @romanan! We'll see how the Chromium bug progresses, but this also feels like something we could potentially fix on our end if that doesn't go anywhere.
As per the update on the Chromium side, it seems that they are saying that it should be fixed in WebView2 as the bug there has been closed now.
Thanks for the update @AndyShawQt - I've pointed the chromium bug to this issue and saw you did the same with the QT bug.
@champnic is there any plan to fix this issue in WebView2?
@KevinShen73 Yes we would like to fix this when we have time, but it's not currently a high priority for us. If we hear more folks asking for this we may fix it sooner.
This issue is annoying and will cause our software crash frequently if WebView2 and QT are used together. Would you help escalate this issue? Thanks.
For those of you hitting this issue, what is your scenario that causes this? Are you loading multiple different web controls at the same time?
One challenge here is that there are already developers (apps and/or components) that have taken a dependency on the window name for things like accessibility or otherwise identifying a WebView2 window, so changing the name everywhere would break them. Changing the name for a specific app would break certain features in that app, but maybe that's acceptable to unblock folks here?
@champnic Yes, we QT and WebView2 in the same process. A solution specific to our process would work.
No idea if it's related. But we are getting something similar. WebView2 works within our application, untill wkhtmltopdf is loaded. I think wkhtmltopdf uses QT as well, As soon as the native dll for wkhtmltopdf is loaded and run once, WebView2 stops initializing with the following errors shown in the output window:
[0512/144657.620:ERROR:validation_errors.cc(106)] Invalid message: VALIDATION_ERROR_UNEXPECTED_NULL_POINTER (null field 8) [0512/144657.620:ERROR:interface_endpoint_client.cc(665)] Message 1699724714 rejected by interface embedded_browser.mojom.EmbeddedBrowser
@champnic would you share what the current status of this bug? It introduced a lot of random crahses in our app.
Hey @buaaji - No specific progress has been made on this bug. I wouldn't expect this to cause random crashes. Can you confirm that you are trying to use QT and that the conflicting HWND names are the cause?
We also face the same issue. Clearly it's due to the HWND name, as mentioned above, recompiling Chromium with a different HWND name fixes the issue. The Chromium and QT issues both says Microsoft has to fix it by chosing a different name strategy in WebView2 - I tend to agree with them.
Any of the three could make the same change (allow specifying a custom HWND name or something similar) - we're just the only ones keeping this item open to track the work :/ unless you have a more specific reason you think WebView2 must be the one to add this functionality?
I've bumped the priority on this item - we'll try and take another look soon.
@champnic yes, we are pretty sure that the HWND name is the cause. Thanks for bumping the priority!
Qt basically includes Chromium as part of Qt WebEngine, so when an application is using that it is using Chromium directly in effect. However when WebView2 is used, then it is a control and therefore it is possible for both to co-exist. Since WebView2 is designed to work as a control vs Qt/Chromium which is designed to work inside an application and as such is not expected to conflict with anything else then WebView2 has to make the change here.
As another factor, both chromium and qt existed before webview2, so IMO, the onus is on webview2 to sidestep the name conflict, especially if the hope is to one day supplant existing embedded browser use cases in Qt.
Description
WebView2 and QT both use the same window name, which causes problems (see https://bugreports.qt.io/browse/QTBUG-85768)
Previously, when our application integrated with CEF, we patched libcef.dll with a custom window name. Since WebView2 is shared at the OS level, we can no longer do that. Version SDK: Runtime: Framework: OS:
Repro Steps
Screenshots
Additional context
AB#32801641