Let cmd-` switch windows again.

chrome/browser/tab_contents/tab_contents_view_mac.mm

Index: chrome/browser/tab_contents/tab_contents_view_mac.mm
diff --git a/chrome/browser/tab_contents/tab_contents_view_mac.mm b/chrome/browser/tab_contents/tab_contents_view_mac.mm
index 61195b1a72f8e49ce8341f5ebc75258fed1ad144..21b4970b4edb7b127ba1a3a4032d5cdaf0284a9f 100644
--- a/chrome/browser/tab_contents/tab_contents_view_mac.mm
+++ b/chrome/browser/tab_contents/tab_contents_view_mac.mm
@@ -2,6 +2,8 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
+#import <Carbon/Carbon.h>
+
 #include "chrome/browser/tab_contents/tab_contents_view_mac.h"
 
 #include <string>
@@ -259,6 +261,10 @@ void TabContentsViewMac::Observe(NotificationType type,
   }
 }
 
+@interface NSApplication(SPI)
+- (void)_cycleWindowsReversed:(BOOL)reversed;

[James Su, 2009/10/15 08:00:49]

Is it ok for us to depend on a private method? It makes me a little nervous. And
what's the difference between _cycleWindows, _cycleWindowsBackwards and
_cycleWindowsReversed?

[Nico, 2009/10/15 15:40:00]

I think it's ok for often-used stuff as long as we check that the function
exists before calling it – that way we don't crash but only lose some
functionality if it goes away. Which we will notice, because when something
that's used often stops working, someone will notice. We do this in several
places already.

WebKit uses this function too (
https://svn.webkit.org/browser/trunk/WebKit/mac/DefaultDelegates/WebDefaultUI...
) and has for years, so this going away all of a sudden is unlikely.

_cycleWindowsReversed: receives a bool argument, while _cycleWindows: and
_cycleWindowsBackwards: seem to receive an (id)sender, so that the latter two
can be used as actions.

+@end
+
 @implementation TabContentsViewCocoa
 
 - (id)initWithTabContentsViewMac:(TabContentsViewMac*)w {
@@ -303,6 +309,25 @@ void TabContentsViewMac::Observe(NotificationType type,
       return;
   }
 
+  // Cmd-` is not in the menu and it's apparently handled by |NSApp sendEvent|
+  // if the application doesn't swallow it. We do, so we need to handle this
+  // key ourself. On foreign keyboards, the "switch windows" key is not the
+  // ` key, so do this by keycode instead of |event characters|.

[James Su, 2009/10/15 08:00:49]

Is Cmd-` the only key handled by |NSApp sendEvent| but not in the menu? I feel
that the right approach is to feed the key event back to NSApp, so that we don't
need to care about how to handle it.

[Nico, 2009/10/15 15:40:00]

Experimental evidence suggests that it really is the only key, but I don't know.
(By "experimental evidence" I mean that it's the only key we received bugs for,
and it's also the only key that needed special handling in other projects I've
seen).

+  if ([event type] == NSKeyDown &&
+      [event keyCode] == kVK_ANSI_Grave &&
+      [NSApp respondsToSelector:@selector(_cycleWindowsReversed:)]) {
+    const NSUInteger kModifierMask = NSShiftKeyMask |
+                                     NSControlKeyMask |
+                                     NSAlternateKeyMask |
+                                     NSCommandKeyMask;
+    if (([event modifierFlags] & kModifierMask) == NSCommandKeyMask)
+      [NSApp _cycleWindowsReversed:NO];
+    else if (([event modifierFlags] & kModifierMask) ==
+        (NSCommandKeyMask | NSShiftKeyMask) &&
+        [NSApp respondsToSelector:@selector(_cycleWindowsReversed:)])
+      [NSApp _cycleWindowsReversed:YES];
+  }
+
   // If this tab is no longer active, it's window will be |nil|. In that case,
   // best ignore the event.
   if (![self window])