CoreWebView2 NewWindow and DevTools windows not showing up - Microsoft UWP Store (Signed app)

[DotNet-Fan]

Microsoft WebView2 experts,

The UWP app has a webview2 control and uses social login to authenticate the user . The webview2 instance is subscribed to the newwindowrequested event and works perfectly when build and executed from the visual studio , opens a new window and authentication works well.
The app is published (msixupload) to the window store for testing and noticed that the social login new window is not coming at all.
To test this i have created a sideload msixbundle and installed it locally and that works perfectly fine .
Why when installed through the Microsoft store applet , the webview2 behaves differently for new window feature. How to fix this as this is critical for social logins.

This is posted in Microsoft Q&A and please see the reference -
https://learn.microsoft.com/en-us/answers/questions/1221866/microsoft-uwp-store-corewebview2-newwindowrequeste

Please advise.

Windows 11 64 - Microsoft Windows [Version 10.0.22621.1413]

Microsoft.UI.Xaml.Controls - v 2.8.2

AB#38775174

[david-risney]

What does your NewWindowRequested event handler do? If you leave the CoreWebView2NewWindowRequestedEventArgs.Handled property false, and you leave the CoreWebView2NewWindowRequestedEventArgs.NewWindow property null, then WebView2 will open the new window for you by itself. However, when running as a UWP app in an appcontainer and signed and properly installed (rather than debugging via VS), WebView2 currently has a bug where it cannot open its own windows like for NewWindowRequested (this bug also applies to opening DevTools via F12 or Ctrl+Shift+I - it cannot open the DevTools window).

[david-risney]

As a workaround to this bug, you can handle the CoreWebView2.NewWindowRequested event yourself, mark Handled true, set the NewWindow property to a new CoreWebView2 that you host in a new window.

[DotNet-Fan]

Hi @david-risney,

Thanks and Appreciate your input.
The newWindowRequested event handler is mainly used for showing a message that a new window will be opened to authenticate using social login frameworks like Google/Facebook.
It sets the CoreWebView2NewWindowRequestedEventArgs.Handled to false and let the popup window open by itself for authentication and once authenticated it closes automatically.
And if a new window is requested from other URLs, it just sets that to the current webview2 instance and it doesn’t open a popup.
e.NewWindow = sender;
I noticed this issue only when I signed the app package, submit to the store, and install it from the Microsoft Store Windows applet.
Any plans for releasing the fix in the coming days?
For the workaround, If I set Handled to true, the NewWindow property to new CoreWebview2 that is hosted in a new UWP ContentDialog and navigate to the Google/Facebook URL, will it close the window automatically once the authentication is successful similar to the normal behavior?
Please advise.

[DotNet-Fan]

Hi @david-risney

It is similiar to webview2 navigating to https://www.twitter.com and when user tries to sign in using Google Account or Apple account , it opens the respective login page in popup window and when the authentication is successful, it closes and the twitter page refreshes with the logged in content.

[david-risney]

Any plans for releasing the fix in the coming days?

Unfortunately, no it is a complicated bug for us.

For the workaround, If I set Handled to true, the NewWindow property to new CoreWebview2 that is hosted in a new UWP ContentDialog and navigate to the Google/Facebook URL, will it close the window automatically once the authentication is successful similar to the normal behavior?

If the window closes that would be the auth page using window.close in JavaScript to close the page. You can watch for that and close your own app window with CoreWebView2.WindowCloseRequested.

[DotNet-Fan]

Thank you @david-risney for your advice. I tried it with WindowCloseRequested event but unfortunately ,for the social logins the webview2 doesn't fire the WindowCloseRequested event at all
For google login i see the console error Uncaught TypeError: Cannot read properties of null (reading 'postMessage').

So i set CoreWebView2.Settings.IsWebMessageEnabled= true , but still the problem persists and the WindowCloseRequested event is not fired.

for facebook login/apple id also once the authentication is successful the event is not fired.

To reproduce you just have to navigate to twitter/pinterest.com and try to login to google/facebook/appleid and in the newwindowrequested event handler show the content dialog that is having authwebview2 control and the authwebview2control is subscribed to WindowCloseRequested.

Social logins with new window are an important features for many apps who rely on social logins and This is very critical piece for webview2 right?

[david-risney]

You could allow the end user to close the window themselves, or you could try to detect that the auth flow is complete. For instance, if you know a URL that auth flow will navigate to when the auth flow is complete, you could watch for that in NavigationStarting and use that to determine that the auth flow is complete.

If the web content isn't attempting to close the window via script, then I'm not sure how the window was closing for you automatically previously. If you can figure that out then I can try to come up with other ideas to help.

[DotNet-Fan]

@david-risney I guess the the close event is not firing for the instance that is being shown in the content dialog. As a temporary workaround i'm not opening the page in a content dialog but instead providing the main webwview2 instance and then based on the window close event then act on the remaining steps of refreshing the actual URL.

[DotNet-Fan]

@david-risney @champnic

The code which was working earlier is broken now . Please help.

In the CoreWebView2.NewWindowRequested handler if you set the Handled true, set the NewWindow property to current webview instance
if (sender != null)
e.NewWindow = sender;

It opens the window in to a new popup and not within the current webview and this is broken now.

Windows 11 64 - Microsoft Windows [Version 10.0.22621.2861]

Microsoft.UI.Xaml.Controls - v 2.8.6

Microsoft EdgeWebview - 120.0.2210.77

[DotNet-Fan]

#4250

[DotNet-Fan]

Hi @david-risney

I had to refer the version 119.0.2151.97 due to an issue #4250 in the 120.0 version.

I have observed a strange issue lately where in an webview2 instance you subscribe to NewWindowRequested event and WindowCloseRequested , then on firsttime these handlers would be hit during open and close popup. But in the same webview2 instance if the popup is called again newwindowrequested event is not fired second time.

Any Idea?

[champnic]

We are also going to use this issue to track adding support for opening the built-in DevTools in a signed UWP app, which is failing for the same underlying reason.

If you need to debug the WebView2 inside of a signed UWP app, please follow the instructions here to use the remote debugging tools:
https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/remote-debugging-desktop

[TheWebartist]

I hope you're doing well. I wanted to follow up on the issue #4557 that I opened a few months ago in May.
I understand that you might have other priorities, but I was wondering if there has been any progress or if there is an estimated timeline for a fix.

Additionally, I wanted to share new information that could help with debugging. Besides encountering the bug when opening the devtools, I’ve also noticed that it can be reproduced when opening a link with the target="_blank" attribute.

Thank you for your time and effort, and please let me know if there’s any other information I can provide to assist with resolving this issue.

Best regards

[pubtom]

@champnic @david-risney When will this issue be fixed?

CoreWebView2 NewWindow windows not showing up in Microsoft UWP Store Signed app

[pubtom]

@champnic @david-risney When will this issue be fixed?

It is a big problem that the new window not showing in a signed store app (UWP)

[pubtom]

@champnic @david-risney When will this issue be fixed?

[champnic]

No update. UWP is lower priority for us these days, so it's unlikely we'll look into this bug for a while.