summaryrefslogtreecommitdiffstats
path: root/chrome/browser/chrome_browser_application_mac.mm
diff options
context:
space:
mode:
authorthakis@chromium.org <thakis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-11-06 02:43:51 +0000
committerthakis@chromium.org <thakis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-11-06 02:43:51 +0000
commit5c87690ac9aed7e975132b301aed90abbe4e0550 (patch)
treec882124c8abfa9f4e06f77c4f5a8ebb06cb301a9 /chrome/browser/chrome_browser_application_mac.mm
parent34437af8727dac421df5ff694eea7c8392ed1038 (diff)
downloadchromium_src-5c87690ac9aed7e975132b301aed90abbe4e0550.zip
chromium_src-5c87690ac9aed7e975132b301aed90abbe4e0550.tar.gz
chromium_src-5c87690ac9aed7e975132b301aed90abbe4e0550.tar.bz2
Do not send input menu toggle events to the web.
This changes us back from the sendEvent:-based approach to the performKeyEquivalent:-based one. The main problem with the pKE: approach was that ctrl-tab toggled the view loop. However, I found an SPI in WebKit's source that enables us to work around that. I tested lots of stuff, but there are of course chances that this regresses something. The only sane way to write unit tests for all that keyhandling crap however is to sendEvent: keys to NSApp and have a complete browser with renderers running, and browser tests don't work on OS X yet :-/ BUG=26115 TEST=Open SysPrefs->Keyboard and configure cmd-space to switch input languages. Go to a page that blocks js events (e.g. http://unixpapa.com/js/testkey.html , check the two left checkboxes), cmd-space should still switch input languages. ) All the cases listed at the end of http://sites.google.com/a/chromium.org/dev/developers/os-x-keyboard-handling . Review URL: http://codereview.chromium.org/363024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31197 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/chrome_browser_application_mac.mm')
-rw-r--r--chrome/browser/chrome_browser_application_mac.mm17
1 files changed, 0 insertions, 17 deletions
diff --git a/chrome/browser/chrome_browser_application_mac.mm b/chrome/browser/chrome_browser_application_mac.mm
index 57c6fab..48bef43 100644
--- a/chrome/browser/chrome_browser_application_mac.mm
+++ b/chrome/browser/chrome_browser_application_mac.mm
@@ -9,7 +9,6 @@
#import "base/scoped_nsobject.h"
#import "base/sys_string_conversions.h"
#import "chrome/app/breakpad_mac.h"
-#import "chrome/browser/cocoa/chrome_event_processing_window.h"
#import "chrome/browser/cocoa/objc_method_swizzle.h"
// The implementation of NSExceptions break various assumptions in the
@@ -243,22 +242,6 @@ BOOL SwizzleNSExceptionInit() {
return [super sendAction:anAction to:aTarget from:sender];
}
-- (void)sendEvent:(NSEvent*)event {
- chrome_application_mac::ScopedSendingEvent scoper(self);
- // The superclass's |sendEvent:| sends keyboard events to the menu and the key
- // view loop before dispatching them to |keyDown:|. Since we want to send keys
- // to the renderer before sending them to the menu, and we never want them to
- // the kev view loop when the web is focussed, we change this behavior.
- if ([[self keyWindow]
- isKindOfClass:[ChromeEventProcessingWindow class]]) {
- if ([static_cast<ChromeEventProcessingWindow*>([self keyWindow])
- shortcircuitEvent:event])
- return;
- }
-
- [super sendEvent:event];
-}
-
// NSExceptions which are caught by the event loop are logged here.
// NSException uses setjmp/longjmp, which can be very bad for C++, so
// we attempt to track and report them.