Removed the code that checks the tab number.

chrome/browser/app_controller_mac.mm

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #import "chrome/browser/app_controller_mac.h"
 
 #include "base/auto_reset.h"
 #include "base/command_line.h"
 #include "base/file_path.h"
 #include "base/mac/foundation_util.h"
@@ skipping 341 matching lines @@
 // "preferences".
 - (TabWindowController*)mainWindowTabController {
   NSWindowController* mainWindowController =
       [[NSApp mainWindow] windowController];
   if ([mainWindowController isKindOfClass:[TabWindowController class]])
     return (TabWindowController*)mainWindowController;
 
   return nil;
 }
 
-// If the window has tabs, make "close window" be cmd-shift-w, otherwise leave
-// it as the normal cmd-w. Capitalization of the key equivalent affects whether
-// the shift modifer is used.
-- (void)adjustCloseWindowMenuItemKeyEquivalent:(BOOL)inHaveTabs {
-  [closeWindowMenuItem_ setKeyEquivalent:(inHaveTabs ? @"W" : @"w")];
+// Make "close window" be cmd-shift-w. Capitalization of the key equivalent
+// affects whether the shift modifer is used.
+- (void)adjustCloseWindowMenuItemKeyEquivalent {
+  [closeWindowMenuItem_ setKeyEquivalent:@"W"];

[Mark Mentovai, 2011/06/06 16:27:15]

Your change comment indicates that this is Command-Shift-W maps to close-window
and Command-W maps to close-tab in the xib already. Are these two functions
still necessary?

[shinyak (Google), 2011/06/07 03:15:57]

This function is still used in fixCloseMenuItemKeyEquivalents, which is called
in delayedFixCloseMenuItemKeyEquivalents. It clears the key combination _to
prevent that from having any bad consequences_, and it is also required to
restore the original key combination. These functions is used to do so. So, they
are still necessary.

[Mark Mentovai, 2011/06/07 03:29:29]

shinyak wrote:
Your explanation seems to gloss over the purpose of
-fixCloseMenuItemKeyEquivalents and -delayedFixCloseMenuItemKeyEquivalents, and
their use with -clearCloseMenuItemKeyEquivalents. Those machinations only exist
to support changing the key combinations on these menu items. If the menu items’
key combinations will no longer change, I question whether they’re necessary any
longer. If closeWindowMenuItem_ is never going to be triggered by anything other
than Command-W, and adjustCloseTabMenuItemKeyEquivalent is never going to be
triggered by anything other than Command-Shift-W, and there}s never any reason
to remove the key equivalents from either menu item, then why is all of this
necessary? The “bad consequences” that require -clearCloseMenuItemKeyEquivalents
only happen when the menu items’ key equivalents are changing.

[shinyak (Google), 2011/06/07 03:43:04]

Ah, OK. I understand your comment. 
The menu items' key combination will not change any more. So I would like to try
to remove this code, too.

On 2011/06/07 03:29:29, Mark Mentovai wrote:

   [closeWindowMenuItem_ setKeyEquivalentModifierMask:NSCommandKeyMask];
 }
 
-// If the window has tabs, make "close tab" take over cmd-w, otherwise it
-// shouldn't have any key-equivalent because it should be disabled.
-- (void)adjustCloseTabMenuItemKeyEquivalent:(BOOL)hasTabs {
-  if (hasTabs) {
-    [closeTabMenuItem_ setKeyEquivalent:@"w"];
-    [closeTabMenuItem_ setKeyEquivalentModifierMask:NSCommandKeyMask];
-  } else {
-    [closeTabMenuItem_ setKeyEquivalent:@""];
-    [closeTabMenuItem_ setKeyEquivalentModifierMask:0];
-  }
+// Make "close tab" be cmd-w.
+- (void)adjustCloseTabMenuItemKeyEquivalent {
+  [closeTabMenuItem_ setKeyEquivalent:@"w"];
+  [closeTabMenuItem_ setKeyEquivalentModifierMask:NSCommandKeyMask];
 }
 
 // Explicitly remove any command-key equivalents from the close tab/window
 // menus so that nothing can go haywire if we get a user action during pending
 // updates.
 - (void)clearCloseMenuItemKeyEquivalents {
   [closeTabMenuItem_ setKeyEquivalent:@""];
   [closeTabMenuItem_ setKeyEquivalentModifierMask:0];
   [closeWindowMenuItem_ setKeyEquivalent:@""];
   [closeWindowMenuItem_ setKeyEquivalentModifierMask:0];
 }
 
 // See if we have a window with tabs open, and adjust the key equivalents for
 // Close Tab/Close Window accordingly.
 - (void)fixCloseMenuItemKeyEquivalents {
   fileMenuUpdatePending_ = NO;
   TabWindowController* tabController = [self keyWindowTabController];
   if (!tabController && ![NSApp keyWindow]) {
     // There might be a small amount of time where there is no key window,
     // so just use our main browser window if there is one.
     tabController = [self mainWindowTabController];
   }
-  BOOL windowWithMultipleTabs =
-      (tabController && [tabController numberOfTabs] > 1);
-  [self adjustCloseWindowMenuItemKeyEquivalent:windowWithMultipleTabs];
-  [self adjustCloseTabMenuItemKeyEquivalent:windowWithMultipleTabs];
+
+  [self adjustCloseWindowMenuItemKeyEquivalent];
+  [self adjustCloseTabMenuItemKeyEquivalent];
 }
 
 // Fix up the "close tab/close window" command-key equivalents. We do this
 // after a delay to ensure that window layer state has been set by the time
 // we do the enabling. This should only be called on the main thread, code that
 // calls this (even as a side-effect) from other threads needs to be fixed.
 - (void)delayedFixCloseMenuItemKeyEquivalents {
   DCHECK([NSThread isMainThread]);
   if (!fileMenuUpdatePending_) {
     // The OS prefers keypresses to timers, so it's possible that a cmd-w
@@ skipping 774 matching lines @@
 
 }  // namespace browser
 
 namespace app_controller_mac {
 
 bool IsOpeningNewWindow() {
   return g_is_opening_new_window;
 }
 
 }  // namespace app_controller_mac