Currently, in BridgedContentView, all keydown events are passed to interpretKeyEvents, which generates the appropriate action messages based on the key bindings. While this works, this does not fully mimic Cocoa behavior. Action messages like moveUp, moveDown etc. in Cocoa, are only meant to be used for text editing commands. But in our flow, they are used for focus traversal etc. Cocoa does all focus traversal before calling keyDown (https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html#//apple_ref/doc/uid/10000060i-CH3-SW10). Hence if we were to map up and down array keys to moveDown and moveUp respectively, focus traversal in menus will also follow this key mapping while it shouldn't.  I think same will be the case if we map Tab to some action command. 

Ideally, key events should be propogated in a way that an action message should be invoked only when it is to be used for text editing. This will also remove the need to generate synthetic Views events during an action message. 


A non nil TextInputClient might be used to detect whether to generate an action message using interpretKeyEvents. However, currently TextInputClient can be non-nil even while a menu is active. Infact, going from the omnibox to the menu, still keeps the omnibox active for text input in MacViewsBrowser, but not in Cocoa (which is a different bug).