[KeyboardLock] Windows key causes start menu to appear |
|||
Issue descriptionThe initial release of the KeyboardLock API did not trap any modifier keys (Alt/Ctrl/Shift/Win). We did this for simplification reasons but the result was that we do not handle the Win key as well as we could.
,
Aug 30
,
Sep 27
I'm working on this now. My plan is to invert the logic in the Windows keyboard hook by only capturing modifier keys. Thus printable chars and extended keys will pass through normally and have intercepted modifiers applied to them when Chrome sees the input.
,
Sep 27
Issue 888199 has been merged into this issue.
,
Sep 27
Issue 876916 has been merged into this issue.
,
Sep 27
Issue 872464 has been merged into this issue.
,
Oct 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/762df375cb5cde323ba6681a38775778939dbddd commit 762df375cb5cde323ba6681a38775778939dbddd Author: Joe Downing <joedow@chromium.org> Date: Wed Oct 03 03:10:04 2018 [KeyboardLock] Update KeyboardHook to only capture modifiers on Windows We've seen a few bugs filed recently for problems related to capturing key events via the low-level hook on Windows. These have all turned out to be related to the fact that the low-level hook intercepts the key events before the OS can update its internal state. An example problem is that WM_CHAR messages are not generated if the hook captures the alpha keys. Since the goal of the hook is to intercept/prevent system key combos, I have decided to invert the logic for the Windows version of the KeyboardHook. Now the hook will only handle Alt, Ctrl, and Win keys. Shift is not intercepted as I want the OS to process it so the correct chars are produced for WM_CHAR messages. The result is that the hook is a bit less powerful / flexible with respect to what it can be asked to capture, however when lock() is called w/o parameters the API will block system combos and the key events the webpage will receive will be the same whether the hook is active or not. This is not a problem on other platforms as ChromeOS/Linux have a 'passive' hook where the key state is calculated before the events are passed to us. MacOS would use an active hook however it hasn't been implemented yet. BUG= 872396 Change-Id: I8dc2416f4ad026a66e766aa3610835612e5bdccc Reviewed-on: https://chromium-review.googlesource.com/c/1162700 Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#596106} [modify] https://crrev.com/762df375cb5cde323ba6681a38775778939dbddd/ui/events/BUILD.gn [modify] https://crrev.com/762df375cb5cde323ba6681a38775778939dbddd/ui/events/keyboard_hook.h [modify] https://crrev.com/762df375cb5cde323ba6681a38775778939dbddd/ui/events/keyboard_hook_base.cc [modify] https://crrev.com/762df375cb5cde323ba6681a38775778939dbddd/ui/events/keyboard_hook_base.h [modify] https://crrev.com/762df375cb5cde323ba6681a38775778939dbddd/ui/events/win/keyboard_hook_win.cc [add] https://crrev.com/762df375cb5cde323ba6681a38775778939dbddd/ui/events/win/keyboard_hook_win.h [add] https://crrev.com/762df375cb5cde323ba6681a38775778939dbddd/ui/events/win/keyboard_hook_win_unittest.cc
,
Oct 16
|
|||
►
Sign in to add a comment |
|||
Comment 1 by joedow@chromium.org
, Aug 30