WebView2 in WPF ScrollViewer causes arrow, home, end keys to not work in INPUT elements

[GCymbala]

Description
When a WebView2 control is contained within a <ScrollViewer> control, input text boxes displayed in the WebView2 no longer respond correctly to arrow, Home and End keys

Version
SDK: Mircorosft.Web.WebView2 1.0.1054.31
Runtime: Microsoft Edge WebView2 Runtime 96.0.1054.62
Framework: WPF
.NET Framework: 4.7.2
OS: Win10

Repro Steps
Create a WPF Windows App with one window containing a DockPanel, ScrollViewer, and WebView2:

<Window x:Class="WpfAppBrowser.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:WpfAppBrowser"
        xmlns:wv2="clr-namespace:Microsoft.Web.WebView2.Wpf;assembly=Microsoft.Web.WebView2.Wpf"
        mc:Ignorable="d"
        Title="MainWindow"
        Height="450"
        Width="800"
>
    <DockPanel>
        <ScrollViewer VerticalScrollBarVisibility="Auto" HorizontalScrollBarVisibility="Auto">
            <wv2:WebView2 Name="webView"
                  Source="https://www.bing.com"
            />
        </ScrollViewer>
    </DockPanel>
</Window>

Once bing.com has loaded, enter some text in the Bing search text input field.
Try to move the cursor within the text input using left, right arrow keys, and Home and End keys.
Expected behavior: Text input cursor moves according to the keys pressed.
Actual behavior: The cursor does not move. It remains at the end of the text.

AB#37648000

[champnic]

Thanks for the bug report @GCymbala - I've added it to our backlog to take a look!

[jotunskij]

I'm having this issue as well. Is a blocker for me, as I'm trying to embed a WYSIWYG editor in a WPF-app, and arrow navigation is impossible, since the WebView2 won't respond to them if placed in a scrollviewer (which is neccessary because I have 5 editors stacked vertically)

[LaughingJohn]

Any progress on this? I'm having the same issue!

[simon1689]

Any solutions or workarounds for this problem?

[M1ch43lS31tz]

facing the same problem. want to implement quill editor with wv2 control in my wpf app... arrow key navigation and therefore keyboard selection with shift+arrow keys is not working at all.

[iXab3r]

Here is a possible solution, which is not a good one from any perspective, but for my application it does the job: override OnPreviewKeyDown in WebView2, do the analysis ("should I pass that exact key to the control?" and, if not, just omit call to base.OnPreviewKeyDown() altogether. This will prevent internal input event system from working and will isolate all inputs inside the browser itself.

Problem statement:

If WebView2 is hosted inside ScrollViewer or ListBox, some key combinations won't work, e.g. PageUp/PageDown or Control+A (with ListBox).

Why?

This is due to how input system works in WebView2 - it tries to simulate WPF events pipeline (with tunneling/bubbling) and relies on the fact that event should not be handled by anyone in the chain for the input to be processed by the browser.

From the docs of WebView2:

  /// Accelerator key presses (e.g. Ctrl+P) that occur within the control will
  /// fire standard key press events such as OnKeyDown. You can suppress the
  /// control's default implementation of an accelerator key press (e.g.
  /// printing, in the case of Ctrl+P) by setting the Handled property of its
  /// EventArgs to true. Also note that the underlying browser process is
  /// blocked while these handlers execute, so:

Pipeline works like this:

1. WebView2 is hosted in a separate window, so all things around how it handles the input have to be handled in non-straighforward manner ("native" to any framework)

2. When WebView2 is instantiated, subscription is done to AcceleratorKeyPressed (which calls ICoreWebView2 add_AcceleratorKeyPressed internally). This is how WebView2 input system is wired with WPF world.

2') There is a flag, called _browserHitTransparent, which will omit that subscription altogether, "fixing" the bug, but you will lose all control over keys pressed in the browser

3. After subscription is done, any key press, considered "accelerator", will be propagated through WPF event system. If nothing marked even as Handled, accelerator will do its job on browser side
   refer to this section for more details

4. So, to get the key working on browser side, you have to make sure that NOTHING handles the same key on WPF side in the whole huge bubbling chain. If something in WPF app has marked event as Handled - it will notify browser-side, that someone "consumed" that keypress, which will stop processing on browser-side.

Unfortunately, this does not work very well with RoutedUICommands and bubbling in WPF.

For example, both ScrollViewer(e.g. PageUp/Down) and ListBox(Ctrl+A) are registering a bunch of input gestures and intercept keypresses (marking them as Handled whenever they catch them and they can process them).
If you have WebView hosted in either of those, any registered input gesture that is also considered "accelerator" will take precedence over anything happening inside browser. In my case text editing was basically impossible as all the usual combinations were consumed by either ScrollViewer or by ListBox

At this point you have two options:

1. Make it so NOTHING will intercept KeyDown event all the way to the root. Doable, but could be very hard - having 0 controls doing input gestures is quite unusual in WPF apps.

2. Somehow prevent the bubbling system from working. E.g. suppressing it at the very beginning. That is my route.

[finepeilei]

Our application is face the same problem too, is there any update of the issue? The team of WV2 is response and solve problems so slowly!!!

[simon1689]

Okay guys. Finally found a solution to the arrows key problem. It has to do with the ScrollViewer in combination with WebView2. This answer on StackOverflow was the solution.

You need to make a new ScrollViewer that inherits from the original and then override the OnKeyDown and OnPreviewKeyDown events as follows:

public class WebView2ScrollViewer : ScrollViewer
{
    protected override void OnKeyDown(KeyEventArgs e)
    {
        if (e.OriginalSource is not WebView2)
        {
            base.OnKeyDown(e);
        }
    }

    protected override void OnPreviewKeyDown(KeyEventArgs e)
    {
        if (e.OriginalSource is not WebView2)
        {
            base.OnPreviewKeyDown(e);
        }
    }
}

Use this ScrollViewer in your view instead of the original. The arrow keys will start working now.

Another strategy is by overriding the OnPreviewKeyDown for WebView2 and using the inherited class:

public class WebView2ScrollViewerFixed: Microsoft.Web.WebView2.Wpf.WebView2
    {
        protected override void OnPreviewKeyDown(KeyEventArgs e)
        {
            return;
        }
    }

[venky8951]

When WebView2 is placed inside a WPF ScrollViewer, the ScrollViewer intercepts navigation keys (arrow keys, Home, End, Page Up/Down) for its own scrolling functionality before they can reach the WebView2 control and subsequently the web content within it.

ScrollViewer treats arrow keys as scroll events, which prevents these key events from being forwarded to input elements inside the WebView2 control.

The recommended workaround is to create a custom ScrollViewer that allows these navigation keys to pass through to the WebView2 control when appropriate. You can implement this by:

• Creating a Custom ScrollViewer that handles the PreviewKeyDown event
• Detecting when WebView2 has focus and allowing navigation keys to bypass the ScrollViewer's default handling
• Selectively preventing key event handling for arrow keys, Home, End, etc. when they should reach the web content