MicrosoftEdge / WebView2Feedback

Feedback and discussions about Microsoft Edge WebView2
https://aka.ms/webview2
452 stars 55 forks source link

Conflict between WebView2 window name & QT #1207

Open romanan opened 3 years ago

romanan commented 3 years ago

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

romanan commented 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

champnic commented 3 years ago

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.

AndyShawQt commented 3 years ago

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.

champnic commented 3 years ago

Thanks for the update @AndyShawQt - I've pointed the chromium bug to this issue and saw you did the same with the QT bug.

KevinShen73 commented 3 years ago

@champnic is there any plan to fix this issue in WebView2?

champnic commented 3 years ago

@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.

naeco2008 commented 3 years ago

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.

champnic commented 3 years ago

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?

szilvaa commented 2 years ago

@champnic Yes, we QT and WebView2 in the same process. A solution specific to our process would work.

ITMATIC-HUSO commented 2 years ago

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

buaaji commented 2 years ago

@champnic would you share what the current status of this bug? It introduced a lot of random crahses in our app.

champnic commented 2 years ago

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?

psmulovics commented 2 years ago

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.

champnic commented 2 years ago

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?

champnic commented 2 years ago

I've bumped the priority on this item - we'll try and take another look soon.

buaaji commented 2 years ago

@champnic yes, we are pretty sure that the HWND name is the cause. Thanks for bumping the priority!

AndyShawQt commented 2 years ago

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.

jeremyong commented 1 year ago

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.