summaryrefslogtreecommitdiffstats
path: root/chrome/browser/extensions/extension_test_api.cc
diff options
context:
space:
mode:
authoryusukes@chromium.org <yusukes@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2012-05-17 04:42:33 +0000
committeryusukes@chromium.org <yusukes@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2012-05-17 04:42:33 +0000
commite7293fa923c53d7e5ea3d38a0b94d6cbc0fb8486 (patch)
tree0c147ea2bd1e085f7b476445f0983d433261412d /chrome/browser/extensions/extension_test_api.cc
parent12ba80a36b9d69af9fdd7435da508c997749fddb (diff)
downloadchromium_src-e7293fa923c53d7e5ea3d38a0b94d6cbc0fb8486.zip
chromium_src-e7293fa923c53d7e5ea3d38a0b94d6cbc0fb8486.tar.gz
chromium_src-e7293fa923c53d7e5ea3d38a0b94d6cbc0fb8486.tar.bz2
Let Chrome app handle Ash accelerators first if the app is launched as a window.
Currently, Ash accelerators are handled at a very early stage, right after a native key event is received by aura::RootWindowHost. This CL change the way of handling Ash accelerators as follows to make it more App friendly: 1. If no window is focused, handle an Ash accelerator immediately in ash/accelerators/accelerator_filter.cc in the same way as before. 2. Otherwise, do not handle it in ash/accelerators/accelerator_filter.cc but let a custom views::FocusManager handle it (see ash/shell.cc). There are 3 types of scenarios here depending on the type of the focused window: 2-a. If the focused window is a browser, and the browser is not for an app, let the custom focus manager pre-handle Ash accelerators before passing it to the browser (see PreHandleKeyboardEvent() in chrome/browser/ui/views/frame/browser_view.cc). 2-b. If the focused window is a browser, and the browser is for an app, let the app handle Ash accelerators first (see chrome/browser/ui/views/frame/browser_view.cc). If the accelerator is not consumed by the app, let the custom focus manager handle it. 2-c. If the focused window is not a browser, let the window handle Ash accelerators first. If the accelerator is not consumed by the window, then let the custom focus manager handle it. This means a WebView without the chrome/browser/ui/ layer can handle Ash accelerators first whenever needed. Other changes: chrome/browser/ui/views/frame/browser_view.cc: Support ET_KEY_RELEASED accelerators in BrowserView::PreHandleKeyboardEvent(). ui/views/focus/focus_manager.cc: Support ET_KEY_RELEASED accelerators. Also fix code for handing VKEY_MENU so that the Shift+Alt+ET_KEY_RELEASED accelerator for Ash could be handled correctly. This CL depends on http://codereview.chromium.org/10377158/ (by jochen), https://chromiumcodereview.appspot.com/10388023, http://codereview.chromium.org/10389035/, and https://chromiumcodereview.appspot.com/10332051/, and should not be submitted until the 4 CLs are landed. BUG=123856 TEST=ran aura_shell_unittests TEST=manual; launch Chromoting app as a window, connect to a Chromoting server, focus Chrome on the remote machine, press Ctrl-n, confirm a new window is opened on the remote machine. Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=135791 Review URL: https://chromiumcodereview.appspot.com/10134036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@137629 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/extensions/extension_test_api.cc')
0 files changed, 0 insertions, 0 deletions