0

I am trying to host a legacy web application within a Webview2 WPF control and it keeps crashing after it opens a new window and tries to write to the document.

The solution needs to interact with both the initial window and the newly opened window, so I am handling the Webview2 NewWindowRequested event like this:

var deferral = e.GetDeferral();

e.Handled = true;
MainWindow mw = new MainWindow
{
    Deferral = deferral,
    Args = e
};

mw.Show();

On CoreWebView2InitializationCompleted

if (Deferral != null)
{
    Args.NewWindow = wv.CoreWebView2;
    Deferral.Complete();
}

Here is the HTML:

Test 
<button onclick="opentwo()">Open</button>

<script type="text/javascript">
    function opentwo() {
        var two = window.open('');
        two.document.open();
        two.document.write('<html><head><title>test</title></head><body>this is the body</body></html>')
        two.document.close();
    }
</script>

I tried handling CoreWebView2 ProcessFailed event, and it fires for both the initial Webview2 and the newly created one as well. ExitCode = -1073741819 ProcessFailedKind = BrowserProcessExited Reason = Unexpected

I am using Webview2 version 100.0.1185.36

Is there a different way I can handle opening the new window to avoid the crash? If I let the new window open using the default simple browser, it works fine. However, I need access to the newly created window.

Any other ideas?

I have created a simple test of this here - https://github.com/attilamn/webview2-document-write-test

attila
  • 2,219
  • 1
  • 11
  • 15
  • I think `deferral.Complete()` must be called from the same event handler, where you call `e.GetDeferral();`. – Poul Bak Apr 13 '22 at 20:56
  • https://www.pedrolamas.com/2017/04/04/await-your-event-handlers-completion-with-deferred-events/ – Poul Bak Apr 13 '22 at 20:57
  • Thanks Poul. Since the e.NewWindow is expecting an initialized CoreWebView2, deferral.Complete cannot be called right away. the deferral is being set to a class level variable "Deferral" of the new window, and then that is used for completion. Everything seems to work normally - it appears to fail with the first window trying to write to the new window's document - document.write. – attila Apr 13 '22 at 21:37
  • Take the code from here: [e.NewWindow = (CoreWebView2)sender still results in a separate instance](https://stackoverflow.com/a/68790332/7444103) -- Since you're using the same Window as popup, use the second `OnNewWindowRequested` handler and create a new `MainWindow` there -- That's a WinForms app, so you need to replace `protected override async void OnLoad(...)` with `protected async override void OnInitialized(...)` -- A quick look at your project shows that you're not awaiting any `async` method. – Jimi Apr 15 '22 at 16:15
  • Change: `public MainWindow() { InitializeComponent(); wv.CoreWebView2InitializationCompleted += Wv_CoreWebView2InitializationCompleted; }` and of course also the overloaded Constructor: `public MainWindow(CoreWebView2Deferral deferral, CoreWebView2NewWindowRequestedEventArgs args) : this() { Deferral = deferral; Args = args; }` -- Set `wv.Source` in `OnInitialized()` after `await wv.EnsureCoreWebView2Async();` – Jimi Apr 15 '22 at 16:15
  • @Jimi - thanks. I tried by creating a new win forms project and using your code from the answer you provided, but it is still crashing when opening the new window and trying to write to the document from the first window. I have updated the repo. – attila Apr 15 '22 at 17:11
  • Since I have no means to verify this functionality at this time, I was going to suggest a couple of changes to test a possible glitch, but now I see what @David Risney is saying... -- Some of the changes I mentioned still stand. You need to await those methods, otherwise you may cause sort of a *race condition* that may prevent the Control from initializing properly. – Jimi Apr 15 '22 at 19:19
  • Good point on the potential for race conditions. I will test against the canary build and see if I can get it to work. – attila Apr 15 '22 at 20:25

1 Answers1

1

This is a bug in the WebView2 Runtime. It is fixed in versions 101.0.1210.8 and higher. See Test upcoming APIs and features for information on trying out a preview version of the WebView2 Runtime that should have your bug fixed and the Microsoft Edge Releases calendar for when the fix will make it to stable (currently predicted for the week of 28-Apr-2022).

At the time of writing, the WebView2 Runtime still has the bug, but the beta, dev, and canary channels all have the fix. The next release of the WebView2 Runtime should include the fix.

David Risney
  • 3,886
  • 15
  • 16
  • Thanks David. I tested with the beta channel and it appears resolved. Any ideas when this fix will make it into the WebView2 Runtime? – attila Apr 15 '22 at 20:54
  • You can check the Edge Release calendar https://learn.microsoft.com/en-us/deployedge/microsoft-edge-release-schedule#microsoft-edge-releases. 1210 says it will get to stable around the week of Apr 28. – David Risney Apr 15 '22 at 21:44