summaryrefslogtreecommitdiffstats
path: root/chrome/browser/ui/cocoa/browser_window_cocoa.mm
diff options
context:
space:
mode:
authorsuzhe@chromium.org <suzhe@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-12-06 19:40:23 +0000
committersuzhe@chromium.org <suzhe@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-12-06 19:40:23 +0000
commit0f72a2dc2d84f60e986337233c37457cb6e59d3e (patch)
tree102313fcdf7521af4914508de962b3b7802fafa6 /chrome/browser/ui/cocoa/browser_window_cocoa.mm
parente90e522650e27a379fe8c3c6fe49b214e830f949 (diff)
downloadchromium_src-0f72a2dc2d84f60e986337233c37457cb6e59d3e.zip
chromium_src-0f72a2dc2d84f60e986337233c37457cb6e59d3e.tar.gz
chromium_src-0f72a2dc2d84f60e986337233c37457cb6e59d3e.tar.bz2
Fix BrowserKeyEventsTest.ReservedAccelerators on Mac 10.6
There are two reasons that cause this problem: 1. See issue http://crbug.com/65375 2. By some reason, when BrowserWindowCocoa::PreHandleKeyboardEvent() is called for Cmd-W, it fails to get its corresponding command id, because the corresponding menu item is not enabled at that time. This CL does following changes: 1. Change testing flow to work around issue 65375. 2. Fix the second problem by always retrieving the corresponding command id regardless of the menu item's state. The reason of the second issue: When Cmd-T gets handled in NSApp, BrowserWindowController's -validateUserInterfaceItem: method will be called for all menu items to determine their enable states and the states will be cached in each menu item. At this time, because there is only one tab, the "Close Tab" menu item will be disabled. Then when sending Cmd-W to the browser, it'll firstly be handled in BrowserWindowCocoa::PreHandleKeyboardEvent() method, which will look up the command id associated to Cmd-W, but at this time, BrowserWindowController's -validateUserInterfaceItem: method does not get called yet, so the corresponding menu item is still not enabled. Then BrowserWindowCocoa::PreHandleKeyboardEvent() will not handle Cmd-W because it cannot find its command id. After removing the check in cr_firesForKeyEvent method, BrowserWindowCocoa::PreHandleKeyboardEvent() method will always get the correct command id of a key equivalent regardless of its enable state, then if it's a reserved key equivalent, it will always be sent to NSApp for handling, which will call BrowserWindowController's -validateUserInterfaceItem: to update the enable states of all menu items. Then if the corresponding menu item is really disabled, NSApp will do nothing and return false, then the key event will be dispatched to web page as normal. BUG=50447 BrowserKeyEventsTest.ReservedAccelerators failed on Mac10.6 Tests (dbg)(1) bot. TEST=The test should not flaky. Review URL: http://codereview.chromium.org/5576002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68369 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/ui/cocoa/browser_window_cocoa.mm')
-rw-r--r--chrome/browser/ui/cocoa/browser_window_cocoa.mm2
1 files changed, 1 insertions, 1 deletions
diff --git a/chrome/browser/ui/cocoa/browser_window_cocoa.mm b/chrome/browser/ui/cocoa/browser_window_cocoa.mm
index d1e7f97..fc86977 100644
--- a/chrome/browser/ui/cocoa/browser_window_cocoa.mm
+++ b/chrome/browser/ui/cocoa/browser_window_cocoa.mm
@@ -465,7 +465,7 @@ void BrowserWindowCocoa::HandleKeyboardEvent(
if (submenu != [NSApp servicesMenu])
result = [self itemForKeyEquivalent:key
menu:submenu];
- } else if ([item cr_firesForKeyEvent:key]) {
+ } else if ([item cr_firesForKeyEventIfEnabled:key]) {
result = item;
}