diff options
| author | thakis@chromium.org <thakis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-10-19 21:19:55 +0000 |
|---|---|---|
| committer | thakis@chromium.org <thakis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-10-19 21:19:55 +0000 |
| commit | 34d28ddce64512e2227c566d47ca238401c57e48 (patch) | |
| tree | 39832d4fc2ff46cb60572f17364a866ced071819 /chrome/browser/cocoa/chrome_event_processing_window.mm | |
| parent | 0f5a3da9fbc074bbb9c63163866ba5d806919d0d (diff) | |
| download | chromium_src-34d28ddce64512e2227c566d47ca238401c57e48.zip chromium_src-34d28ddce64512e2227c566d47ca238401c57e48.tar.gz chromium_src-34d28ddce64512e2227c566d47ca238401c57e48.tar.bz2 | |
Make window cycling work even if you change it to something else than cmd-` in sysprefs.
Instead of just dispatching to the menu after a key comes back from the renderer, do a complete re-dispatch to NSApp (so that the event gets to the menu and cmd-` handlers) but then ignore it when it comes back to the web (because we already sent this event to the renderer once).
BUG=24817
TEST=Open sysprefs, change keyboard shortcut for "Move focus to next window in active application" to e.g. cmd-\. Open two chrome windows, focus the web, hit cmd-\. It should switch windows. All other keyboard shortcuts should still work (test that ctrl-tab works when web has focus, test backspace when text field is focussed in web, when background is focussed in web, when IME is active, test hitting cmd-1/2 when omnibox or web have focus, hit cmd-left when omnibox, textbox in web, background in web has focus, test that cmd-f in docs still opens doc's find interface)
Review URL: http://codereview.chromium.org/303002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29458 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/cocoa/chrome_event_processing_window.mm')
| -rw-r--r-- | chrome/browser/cocoa/chrome_event_processing_window.mm | 38 |
1 files changed, 35 insertions, 3 deletions
diff --git a/chrome/browser/cocoa/chrome_event_processing_window.mm b/chrome/browser/cocoa/chrome_event_processing_window.mm index 8633c1c..c1b270f 100644 --- a/chrome/browser/cocoa/chrome_event_processing_window.mm +++ b/chrome/browser/cocoa/chrome_event_processing_window.mm @@ -50,10 +50,30 @@ typedef int (*KeyToCommandMapper)(bool, bool, bool, int); fromTable:CommandForBrowserKeyboardShortcut]; } +- (BOOL)shortcircuitEvent:(NSEvent*)event { + if (!redispatchingEvent_ && + ([event type] == NSKeyDown || [event type] == NSKeyUp)) { + if ([[self firstResponder] + isKindOfClass:[RenderWidgetHostViewCocoa class]]) { + // No other mac browser sends keyup() for keyboard equivalents, so let's + // suppress this. + if (([event modifierFlags] & NSCommandKeyMask) && [event type] == NSKeyUp) + return YES; + + RenderWidgetHostViewCocoa* rwhv = static_cast<RenderWidgetHostViewCocoa*>( + [self firstResponder]); + [rwhv keyEvent:event]; + return YES; + } + } + return NO; +} + - (BOOL)performKeyEquivalent:(NSEvent*)event { - // We have some magic in |CrApplication sendEvent:| that always sends key - // events to |RWHVCocoa keyEvent:| so that cocoa doesn't have a chance to - // intercept it. + if (redispatchingEvent_) + return NO; + + // |shortcircuitEvent:| should handle all events directed to the RWHV. DCHECK(![[self firstResponder] isKindOfClass:[RenderWidgetHostViewCocoa class]]); @@ -66,5 +86,17 @@ typedef int (*KeyToCommandMapper)(bool, bool, bool, int); return [super performKeyEquivalent:event]; } +- (void)redispatchEvent:(NSEvent*)event { + DCHECK([event window] == self); + redispatchingEvent_ = YES; + [NSApp sendEvent:event]; + redispatchingEvent_ = NO; +} + +- (void)sendEvent:(NSEvent*)event { + if (!redispatchingEvent_) + [super sendEvent:event]; +} + @end // ChromeEventProcessingWindow |