Getting Started Win32: WebView2 search box (Ctrl-F) steals activation from frame window and is unanchored

[amtopel]

I apologize if this has been reported before, but I could not locate it.

If you run the "Win32_GettingStarted" sample (in the WebView2Samples repo), and then hit Ctrl-F to do a search (on the Bing page that's loaded up by default), the webview's search box will appear. But it will steal activation from the main frame window--i.e., the frame caption/non-client area will become grayed out. Furthermore, if you start to move the frame window around, the search box will not move with it. It remains unanchored.

Based on the way the ordinary Edge browser works, you'd expect (a) the search box not to steal activation from the frame window, and (b) the search box to move around with the frame window as it moves.

I'm using the WebView2 package 1.0.1150.38, on Windows 8.1.

Thanks for any help on this issue.

AB#38546000

[champnic]

Hey @amtopel - thanks for this bug report. Can you try running the full sample app "WebView2APISample" and see if you still see the issue there? We think this is just a bug in the Getting Started app, which needs to call NotifyParentWindowChanged. I've added this bug to our backlog to update that app.

[hunkydoryrepair]

pretty sure this has been reported. I've been waiting for a fix.
Although the latest (1150.38) makes the problem worse. I can get the search box to come up once, but after closing it, or getting into the activation lock state, CTRL-F no longer works. In fact, other keys, like F12, no longer work, either.

[hunkydoryrepair]

See bug #1727

The Search Box is its own top level window, but somehow it prevents the application top level window from being activated, and also becomes unresponsive itself. Appears to be some kind of deadlock situation.

[hunkydoryrepair]

The problem has been demostrated on WPF, WinForms and Win32. NotifyParentWindowChanged doesn't make much sense because the search box is not in the hierarchy of the main app window. So far, no solution has been presented for #1727

[amtopel]

Also, if your webview is in a nested child window, how does it know that its top-level ancestor is moving around and that you need to call NotifyParentWindowPositionChanged?

[hunkydoryrepair]

Also, if your webview is in a nested child window, how does it know that its top-level ancestor is moving around and that you need to call NotifyParentWindowPositionChanged?

That is a red herring. This bug is reproducible without moving the application window at all. Just switching focus to another app and back a couple times will freeze things up.

[champnic]

@hunkydoryrepair We think you're right about this. We're keeping this open separately, but we are currently looking into #1727 and believe this shares the same root cause.

[champnic]

We think this was fixed a while back and forgot to update as we were tracking in a different item:
#1727 (comment)

If you see this is still happening, please let us know and I can reopen. Thanks!