New issue
Advanced search Search tips

Issue 872396 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 16
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug



Sign in to add a comment

[KeyboardLock] Windows key causes start menu to appear

Project Member Reported by joedow@chromium.org, Aug 8

Issue description

The 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.



 
Labels: -M-70 M-71
Cc: joedow@chromium.org garykac@chromium.org
 Issue 878623  has been merged into this issue.
Status: Started (was: Assigned)
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.
Issue 888199 has been merged into this issue.
Issue 876916 has been merged into this issue.
 Issue 872464  has been merged into this issue.
Project Member

Comment 7 by bugdroid1@chromium.org, 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

Status: Fixed (was: Started)

Sign in to add a comment