diff options
author | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-03-07 22:21:52 +0000 |
---|---|---|
committer | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-03-07 22:21:52 +0000 |
commit | 45a6846c2efb0b934e3baed72027cba4ec1751b9 (patch) | |
tree | eaeef11ca280c09f35e641038825c753d2ea94f4 /sync/android | |
parent | 2450c2dc0d0e5335fe6d35a29d5a550b343c5e42 (diff) | |
download | chromium_src-45a6846c2efb0b934e3baed72027cba4ec1751b9.zip chromium_src-45a6846c2efb0b934e3baed72027cba4ec1751b9.tar.gz chromium_src-45a6846c2efb0b934e3baed72027cba4ec1751b9.tar.bz2 |
Ensure that menus put in Chrome ASH on Windows 8 are operatable using the keyboard.
When a menu is displayed we enter a nested message loop in the Chrome Browser. This loop
expects to receive native events for WM_KEYDOWN/WM_KEYUP/WM_CHAR, etc. In desktop AURA this
works well because the native events come in through the standard OS mechanism.
In ASH we send over fabricated keyboard events from the viewer process to the browser where
these are dispatched to the root window. This causes the secondary loop to never receive these
events.
Fix for now is to check if we are in a nested loop in the RemoteRootWindowHostWin IPC handlers
and post the corresponding native event back to the queue.
The other change in this CL is to add an event handler to listen for accelerator events in the viewer
process. This is necessary to receive keystrokes like Alt, etc. We send over the same keydown/keyup/character
IPC's when we receive this event.
BUG=180738
R=cpu
TBR=ben
TEST=Will look into an ash based test for this in a subsequent CL.
Review URL: https://codereview.chromium.org/12558008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@186797 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'sync/android')
0 files changed, 0 insertions, 0 deletions