Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WebView2.KeyDown does not work correctly with modifiers #1216

Closed
fvanheeswijk opened this issue Apr 23, 2021 · 10 comments
Closed

WebView2.KeyDown does not work correctly with modifiers #1216

fvanheeswijk opened this issue Apr 23, 2021 · 10 comments
Assignees
@zhuhaichao518
Labels
bug Something isn't working tracked We are tracking this work internally.

Comments

@fvanheeswijk
Copy link

fvanheeswijk commented Apr 23, 2021 •
edited by champnic
Loading

Description
When you press Shift+F8 and the KeyDown event gets triggered it registers as F8 and not as Shift+F8

Version
SDK: 1.0.824-prerelease
Runtime: Stable Edge 90
Framework: WinForms
OS: Win10, 20H2

Repro Steps
Take the following project as example:

using System;
using System.Collections.Generic;
using System.Drawing;
using System.Linq;
using System.Threading.Tasks;
using System.Windows.Forms;

using Microsoft.Web.WebView2.WinForms;

namespace WebView2BugModifiers
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(CreateTestForm());
        }

        public static Form CreateTestForm()
        {
            var form = new Form
            {
                Size = new Size(1280, 1024)
            };

            var webView2 = new WebView2
            {
                Dock = DockStyle.Fill,
                Source = new Uri(@"https://github.com/MicrosoftEdge/WebView2Feedback/")
            };

            webView2.KeyDown += (sender, e) =>
            {
                return;
            };

            form.Controls.Add(webView2);

            return form;
        }
    }
}

When you set a breakpoint in the KeyDown event handler and then press Shift+F8 you will see that no modifier is listed. We expect that the shift is listed as a modifier.

AB#34280866
@fvanheeswijk fvanheeswijk added the bug Something isn't working label Apr 23, 2021
@champnic
Copy link
Member

Thanks for catching this, I've confirmed on our end. I've added a bug to our backlog to get this fixed.

@champnic champnic added the tracked We are tracking this work internally. label Apr 23, 2021
@champnic champnic self-assigned this Apr 23, 2021
@fvanheeswijk
Copy link
Author

An extra addition to this: Ctrl does not seem to work correctly either, when I press Ctrl + W for example then KeyDown returns that the Control key has been pressed, my W has disappeared nor is Control set as modifier.

@JaseRandall
Copy link

Would there be an update/ETA available please for the KeyDown bug fix?

I'm trying to handle some of the BrowserAcceleratorKeys, such as CTRL-T (new tab) however the KeyDown events always has Control = false and the Modifiers are always None.
As per the image below, I pressed the control key but the only values to reflect that is the KeyCode and KeyValue.
image

I can confirm other BrowserAcceleratorKeys, such as Ctrl-F and Ctrl-P are working correctly, so it's not as if BrowserAcceleratorKeys are set to false.

@champnic
Copy link
Member

champnic commented Sep 8, 2021

No update here. The current workaround is to keep track of when keys are being pushed (through a map or similar) and check that way, because as you note the "control" and the "T" are coming in separate events. Devs have also been using script to catch and handle keyboard shortcuts more easily, for example: #1684 (comment)

We know this is a pain point, and is one of the upcoming .NET scenarios we're going to look at improving.

@fvanheeswijk
Copy link
Author

Is there any news on this?

@champnic
Copy link
Member

@zhuhaichao518 Would this scenario be improved by your hit-transparent work? If so, can you share some details on how to enable that here?

@spencerb02
Copy link

2 and a half years later, any update on this?

@champnic champnic assigned zhuhaichao518 and unassigned champnic Jan 18, 2024
@wnayes
Copy link

wnayes commented Jun 12, 2024

Another workaround option, in case it helps someone:

If you are working with a WinForms Control/Form, then you have access to the base Control.ModifierKeys property, which is a property that holds the current modifier key state. This seems to be a straightforward alternative to trying to use the Modifiers on the KeyEventArgs.

@zhuhaichao518
Copy link
Contributor

zhuhaichao518 commented Jun 19, 2024 •
edited
Loading

@wnayes Thanks for your suggestion!
@spencerb02 We have fixed it on our side and I expect it to be fixed in the sdk following edge 128 release.

@champnic
Copy link
Member

champnic commented Aug 2, 2024

This is resolved on the latest pre-release SDK and upcoming release SDK in about a week.

@champnic champnic closed this as completed Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@zhuhaichao518 zhuhaichao518

Labels
bug Something isn't working tracked We are tracking this work internally.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@wnayes @spencerb02 @JaseRandall @fvanheeswijk @champnic @zhuhaichao518