Short-circuit events rwhvmac if it's focussed.

Short-circuit events rwhvmac if it's focussed.

This way the key view loop can't steal our events. This effectively reverts part of http://codereview.chromium.org/242069 and instead takes a bit from http://codereview.chromium.org/271054 .

BUG=24921
TEST=Open 2 tabs. Focus web. Ctrl-tab should switch tabs. Cmd-1/2 should switch tabs. Hitting backspace should go back if no textbox is focusses in the web, else it should delete in the textbox. Hitting cmd-f in docs should still open docs custom search interface.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=29396

[Nico, 2009-10-19 05:29:49]

I couldn't find a good way to hack around the key view event loop, and this
approach is arguably cleaner anyway :-P

James knew it all along.

[James Su, 2009-10-19 09:35:01]

LGTM. Just wondering if it's necessary to send the unhandled key events back to
|NSApp sendEvent:|.

On 2009/10/19 05:29:49, Nico wrote:
> I couldn't find a good way to hack around the key view event loop, and this
> approach is arguably cleaner anyway :-P
> 
> James knew it all along.

[Avi (use Gerrit), 2009-10-19 13:57:15]

Sigh. If that's what works...

LG

[pink (ping after 24hrs), 2009-10-19 15:18:24]

http://codereview.chromium.org/300002/diff/2001/3001
File chrome/browser/chrome_application_mac.mm (right):

http://codereview.chromium.org/300002/diff/2001/3001#newcode193
Line 193: if ([event type] == NSKeyDown || [event type] == NSKeyUp) {
I really dislike the app controller having this kind of knowledge. Makes it hard
to change the impl classes under the hood. Can you at least move this chunk into
BrowserWindowController and have it do the checks and dispatch? It's more
sensical to me that the browser knows about RWHVC's.

[Nico, 2009-10-19 20:06:43]

http://codereview.chromium.org/300002/diff/2001/3001
File chrome/browser/chrome_application_mac.mm (right):

http://codereview.chromium.org/300002/diff/2001/3001#newcode193
Line 193: if ([event type] == NSKeyDown || [event type] == NSKeyUp) {
On 2009/10/19 15:18:24, pink wrote:
> I really dislike the app controller having this kind of knowledge. Makes it
hard
> to change the impl classes under the hood. Can you at least move this chunk
into
> BrowserWindowController and have it do the checks and dispatch? It's more
> sensical to me that the browser knows about RWHVC's.

I'm addressing this comment (and more) in http://codereview.chromium.org/303002
.

[Mark Mentovai, 2009-10-22 20:44:36]

Startup time was infrequently over 300ms before this change, and now it's
infrequently UNDER 300ms.

Might not be this change, though.  It's hard to work out a precise window.

http://codereview.chromium.org/300002/diff/2001/3001
File chrome/browser/chrome_application_mac.mm (right):

http://codereview.chromium.org/300002/diff/2001/3001#newcode188
Line 188: - (void)sendEvent:(NSEvent*)event {
This change may have regressed startup time, but the regression was within the
range of jitter, so it's kind of hard to tell.

http://build.chromium.org/buildbot/perf/mac-release-10.5/startup/report.html?...