App using WebView2 becomes unresponsive due to infinite 0x403 message posting.

[cylvoon]

In my MFC app, I embed webview2 in a dialog. Since the latest runtime update, in many cases, when I close the browser dialog, my app hangs. When debugging, it's busy handling infinite 0x403 message (wParam being always 0xBABE, lParam cycling over a few different values).

With spy++ (when spy++ manage to attach to the window, which often fails, no idea why), you can see the messages. It never ends.

EDIT: I finally found a way to test with the previous runtime version available 108.0.1462.76, and the problem doesn't exist.

SDK: 1.0.1518.46 Runtime: 109.0.1518.52 Framework: MFC OS: Win10

AB#43218978

[cylvoon]

@champnic Sorry to tag you, but this issue is really blocking. The webview2 update has reached most of windows computers and our customers can't work anymore. Please have a look at this.

[champnic]

Hey @cylvoon - we've had some issues with that runtime version recently fixed in 109.0.1518.61. Can you try again with that newer version (should have rolled out this weekend) and see if that resolves the issue? If not we'll need some extra info on the scenario such as a sample app which reproduces the issue, or a trace.

[cylvoon]

Hi @champnic , thanx for your reply. I'm now at 109.0.1518.70, and the problem remains... I might be mistaken, but it seems to be even worse. Now this 0xBABE is blasted as soon as the dialog containing the webview2 is shown.

In the meantime, it'll be hard to create a sample app for you. let's say I'm busing working around the different cases where our apps hang because of this, and it's a real pain (in the ..) 😩 . What I know, is that, the only workaround that's worked so far, is posting a message to delay some process. But sometimes I have to delay the webview2 dialog itself, sometimes the dialog that may come right after... So it probably means 0xBABE messages will eventually stop...

Honestly, this 0xBABE msg must be easy to track in your code. Besides, you can diff with the version that worked. You're definitely in a better place than me to find info about the problem! And I really think dirty things are done with the message loop in there...

The only specific thing in my case, is putting a webview2 inside a MFC CDialog, nothing fancy :) You may want to try and see if it works!

[Oryxamus]

I'm posting here even if this may be a different issue, but it's also occurring in a MFC application that worked previously. It doesn't work with the two runtimes I have, 109.0.1518.61 and 109.0.1518.70. I first noticed the problem on January 17, 2023, but it's possible it was broken for a while before that. I have a test program from December 27, 2022 that I do not think exhibited this behavior (or somehow I did not notice it).

Previous developers on our product had issues hosting WebView2 in a CDialog shown via DoModal, so instead the dialog is shown via Create/ShowWindow, and the code runs a message loop to pass messages on to the dialog:

    while( dialog->IsWindowVisible() && GetMessage(&msg, nullptr, 0, 0) )
    {
        if( !dialog->IsDialogMessage(&msg) )
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }

This is all from 2021, so it was working fine for over a year. Now it works, somewhat. The dialog shows, the web content is rendered, and mouse events are handled. However, no keystrokes are processed, and when I open the DevTools window (via right-click), then mouse events are no longer handled. The debug output window is filled with issues like this that previously were not shown:

Microsoft C++ exception: winrt::hresult_class_not_available at memory location 0x00FFD5E0. WinRT originate error - 0x80040111 : 'Windows.Storage.AccessCache.StorageApplicationPermissionsBrokered'.

And tons of these about input-synchronous calls:

ReturnHr(2) tid(37c0) 8001010D An outgoing call cannot be made since the application is dispatching an input-synchronous call.

In our code, the problem comes when this code is executed from a background thread (which calls up to the UI thread to display the window). So if I:

1) Display this dialog on the main UI thread before launching the background thread, it displays fine, with none of the above debug messages.

2) Start a background thread, which eventually uses SendMessage to send a message to the UI thread, which then displays the dialog, I get the above messages and the dialog is partially unresponsive.

This second scenario is the problem, as it used to work.

Hopefully I'm not hijacking a thread about a totally different issue, but it seems like the problem @cylvoon is reporting may be related to this one.

If needed, I can create a simple application to show this behavior.

[champnic]

@bradp0721 Can you take a quick look at this thread and see if anything obvious is happening here? Otherwise I'll open a bug for us to dig into more.

[Oryxamus]

I should add that my colleague tested our program with Spy++ and got the same infinite 0x403 messages that the original poster mentions.

[bradp0721]

I've marked this tracked. From the original post, the 0x403 message is for WM_USER+3 window messages. I was not able to find anything in our code that is using that window message. The debug output window message is interesting. WebView2 does use the Windows.Storage.AccessCache for IStorageItemAccessList, although I thought that only used for UWP scenarios. That might explain the debug output window, but without debugging it's not immediately obvious why that would result in an infinite flood of WM_USER+3 messages.

[Oryxamus]

As an update to this, I found old versions of the runtime and things work up to 108.0.1462.76.x86. The 109 runtime and 110 do not work. Below are the differences in the debug output window running the same code using 108 vs. 109, with 108 on the left. As @bradp0721 mentioned, my guess is that something about Windows.Storage.AccessCache is causing the problem:

[lindexi]

Same behavior in WPF application without WebView2, see https://github.com/dotnet/wpf/issues/8347

@cylvoon Could you add the stacktrace? Maybe this issues is not the WebView2 issues, and this issues may be the UIA issues.