WebView2 shortcuts not working when focus is inside WebView2

[云漠星河 (yunmoxinghe)]

When the focus is inside a WebView2 control, WinUI's keyboard accelerator/hotkey APIs stop working. The shortcut messages appear to be swallowed by WebView2 and never reach the application.

How can I make shortcut keys work globally, regardless of whether the focus is on WinUI or inside WebView2, without having the key events consumed by WebView2?

[Serge Yudin (yudin-s)]

Handle the shortcut at the WebView2 controller level, not only with WinUI KeyboardAccelerator / KeyDown handlers.

When focus is inside the web content, WebView2 owns that input path first. The WebView2 API surface for this is CoreWebView2Controller.AcceleratorKeyPressed. That event is designed to fire for accelerator keys even when the WebView has focus, and you can mark the event handled before WebView2/browser processing consumes it.

The pattern is:

webView.CoreWebView2InitializationCompleted += (s, e) =>
{
    if (!e.IsSuccess)
        return;

    webView.CoreWebView2.Settings.AreBrowserAcceleratorKeysEnabled = false;

    webView.CoreWebView2Controller.AcceleratorKeyPressed += (_, args) =>
    {
        if (args.KeyEventKind != CoreWebView2KeyEventKind.KeyDown &&
            args.KeyEventKind != CoreWebView2KeyEventKind.SystemKeyDown)
            return;

        // Check your real shortcut/modifier combination here. In WinUI apps,
        // modifier state is usually read with InputKeyboardSource.GetKeyStateForCurrentThread(...).
        if (IsMyAppShortcut(args.VirtualKey))
        {
            args.Handled = true;
            DispatcherQueue.TryEnqueue(() => RunMyAppShortcut(args.VirtualKey));
        }
    };
};

Two details matter:

• AreBrowserAcceleratorKeysEnabled = false only disables browser accelerators such as browser print/save/navigation shortcuts. It does not make WinUI accelerators automatically receive all keys from inside the page.
• AcceleratorKeyPressed is still the place to intercept the keys you want to reserve for the host app. Do not mark normal editing/navigation keys handled unless they really are your app-level shortcuts, or you will break typing inside the page.

So the practical answer is: keep your normal WinUI accelerators for native focus, and mirror the same command routing from CoreWebView2Controller.AcceleratorKeyPressed for WebView focus. For text-entry pages, keep that handler narrowly scoped to the shortcuts that must be global.

If this solves the WebView focus case, please mark it as answered so others know to use the WebView2 controller accelerator event rather than only WinUI keyboard APIs.

[云漠星河 (yunmoxinghe)]

It seems WinUI can't use this?

[云漠星河 (yunmoxinghe)]

CoreWebView2Controller.AcceleratorKeyPressed is an event of the CoreWebView2Controller class, but the WinUI 3 Microsoft.UI.Xaml.Controls.WebView2 class only exposes the CoreWebView2 property？

[Serge Yudin (yudin-s)]

Yes, you are right to question that. My earlier snippet was for hosting paths where you can access the CoreWebView2Controller directly. The WinUI 3 XAML Microsoft.UI.Xaml.Controls.WebView2 wrapper exposes CoreWebView2, but it does not expose the controller object/event in the same way.

So for a WinUI 3 XAML WebView2 control the correction is:

• CoreWebView2Controller.AcceleratorKeyPressed is the WebView2 API that handles this at the controller/input layer. Microsoft documents keyboard accelerators under the controller API, not under CoreWebView2.
• If you only have the WinUI XAML WebView2 control, webView.CoreWebView2.Settings.AreBrowserAcceleratorKeysEnabled = false can stop WebView2 browser shortcuts, but it still does not route those keys into WinUI KeyboardAccelerator automatically.
• For pages you control, the practical workaround is usually JavaScript keydown in the page plus chrome.webview.postMessage(...) back to the host for the shortcut commands you want global.
• If you need native interception for pages you do not control, then the XAML wrapper may be the limiting part; you would need a host path that gives you the underlying controller/input event, or this is worth tracking as a WebView2 WinUI API gap.

So yes: your WinUI observation is valid. My first answer should have separated the controller-level WebView2 API from what the WinUI XAML wrapper actually exposes.