WinForms: Unable to focus WebView2 when it's the only focusable control on a form

[billybooth]

As discussed in #185, which appears to be related, when the WebView2 is the only focusable control on a WinForms form, the inner Chromium window cannot receive input focus either programattically via WebView2.Focus() or via the keyboard/tab stops.

This issue is present in the 0.9.579 prerelease and can easily be replicated by simply removing (or disabling) all of the focusable controls except the WebView2 from the WebView2Samples WinForms sample.

Not a huge deal (can be worked around), but just wanted to let you know. Thanks again for all the work you're doing on this. Very much looking forward to being able to leverage a modern web view!

AB#28588555

[pagoe-msft]

@billybooth

Thanks so much for pointing this out! Out of curiosity, could you give us some context on what you're building and what scenarios this could potentially be an issue?

I've filed a bug for us to investigate further!

[billybooth]

I acknowledge it's probably not a common scenario to have a WebView2 on a form with no other focusable controls, but the initial work I'm doing with it involves the end-user needing to authenticate against an external/upstream identity provider. We basically present an authentication dialog containing only a WebView2 similar to the ones presented, by say Visual Studio or GitHub Desktop on Windows:

Such a scenario where the user is dropped into a WebView2 with default inputs makes the focus problem very apparent. It can obviously be worked around by putting an additional focusable control out of sight and disabling it after the WebView2 receives focus, but the same workaround needs to be applied whenever the form is activated, so I wouldn't mind seeing this one fixed. 😉

[ShaunLoganOracle]

I have a similar use case as @billybooth - using a window/form with only a WebView2 control for authenticating via 3rd party web apps.

[billybooth]

@ShaunLoganOracle, it's working beautifully for us, btw, although the discussion in #374 is making me a bit nervous.

[jamesoli]

@billybooth I'm currently trying to reproduce the issue but not exactly sure what your app is doing. I took the WebView2Samples app, stripped out everything besides the webview, and navigated to a simple page with a form and it had focus.

Can you describe in a little more detail about how you're trying to set focus? For example, is it through JavaScript or through C#?

[billybooth]

@jamesoli, thanks for getting to this one. I haven't updated my own project in a bit, but I just pulled 1.0.721-prerelease into the WebView2WindowsFormsBrowser from the WebView2Samples and find that the issue reported here is fixed. Previously, unless you used the mouse to click on the webview2, you could not put keyboard focus into the DOM (via the tab key or focusing the webview2 control via C#) at all when the webview2 was the only control on a form. That no longer appears to be the case. 👍

That said, in 1.0.721-prerelease, there are still some apparent focus issues. For example, in the vanilla WebView2Samples app with all of the controls on the form, attempt to set keyboard focus to the search input element (it has an autofocus attribute) of https://www.bing.com/ without using the mouse or JavaScript. Tabbing into the webview2 control or setting focus to the webview2 control programmatically via C# should set the keyboard focus to the default input. When I focus the control, I get accelerator key events but I can't get to the DOM without tabbing into it. The basic problem I have is that I would like the webview2 control, when focused, to behave like the Edge browser with respect to keyboard input focus, i.e., when I navigate to a page, I would like the default form input to be focused as it is in a proper browser, and that simply isn't the case through 1.0.721-prerelease.

Thanks again for your time and consideration on this one!

[billybooth]

One aside noted in this issue report was the loss of input focus when a form containing a WebView2 is deactivated and then reactivated. That still occurs in the vanilla WebView2Samples; if you put focus on the search input element of https://www.bing.com/, then deactivate the BrowserForm and subsequently reactivate it, keyboard focus is not restored to the previously focused input element. In this case, the WebView2 gives up control focus entirely. I could file a new issue if you'd like, but it seems that all of these focus issues are pretty closely related and should be rolled into #721

Edit: To be clear about all of this, it wouldn't bother me one bit if I were required to focus the C# control after navigation or after parent form activation, there just doesn't appear to be a reliable approach to navigating to an arbitrary page and allowing a default input element to receive input focus. Neither does there seem to be a way on the C# side to activate/focus the control and have input focus restored.

[jamesoli]

You're right that currently when the WebView2 control is focused, it doesn't auto focus by default. This is due to how we host the actual content for the WebView.

In Win32 world, we have an API called Move Focus that does what you're describing.

For WinForms, I think we should have some way for the actual content of the WebView to be able to get focus. My thought is that webView2Control.Focus() should just work and do what you're describing. This would require us to do some underlying work.

There are other options like bringing over the MoveFocus API but I'm not hot on that option.

[champnic]

This should be fixed in the 1.0.781-prerelease package. Thanks!