Trent, let me know if you want me to investigate this. 

OmniboxView isn't specific to MacViews, but will pick an implementation based on the mac_views_browser setting. E.g. the following Cocoa files depend on it

browser/ui/cocoa/omnibox/omnibox_view_mac.h:#include "components/omnibox/browser/omnibox_view.h"
browser/ui/cocoa/toolbar/toolbar_controller.mm:#include "components/omnibox/browser/omnibox_view.h"


With mac_views_browser=1, it fails with the following (all OSes - not just Sierra), which I think we know about already.
 [40320:1295:0720/112128:FATAL:textfield.cc(1515)] Check failed: ui::TextEditCommand::INVALID_COMMAND == scheduled_text_edit_command_ (54 vs. 48)


It looks like it might be crashing, which is probably bad :/. We'll need to rev up a debug build on the sierra machine.

Seems like a bug inside AppKit with the way it handles the synthetically generated event

Process 96294 stopped
* thread #1: tid = 0x279392, 0x00007fff9ec3f779 AppKit`-[NSEvent _eventWithModifiers:] + 197, name = 'CrBrowserMain', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
    frame #0: 0x00007fff9ec3f779 AppKit`-[NSEvent _eventWithModifiers:] + 197
(lldb) bt
* thread #1: tid = 0x279392, 0x00007fff9ec3f779 AppKit`-[NSEvent _eventWithModifiers:] + 197, name = 'CrBrowserMain', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
  * frame #0: 0x00007fff9ec3f779 AppKit`-[NSEvent _eventWithModifiers:] + 197
    frame #1: 0x00007fff9ede4a32 AppKit`-[NSApplication(NSEvent) sendEvent:] + 3550
    frame #2: 0x00000001014d43cc interactive_ui_tests`__34-[BrowserCrApplication sendEvent:]_block_invoke + 172 at chrome_browser_application_mac.mm:343
    frame #3: 0x0000000109ce369a libbase.dylib`base::mac::CallWithEHFrame(void () block_pointer) + 10 at call_with_eh_frame_asm.S:36
    frame #4: 0x00000001014d4318 interactive_ui_tests`-[BrowserCrApplication sendEvent:] + 72 at chrome_browser_application_mac.mm:327
    frame #5: 0x00000001002c1139 interactive_ui_tests`SendKeyPressNotifyWhenDone + 1737 at ui_controls_mac.mm:282
    frame #6: 0x000000010011c883 interactive_ui_tests`::SendKeyPressToWindowSync() + 115 at interactive_test_utils.cc:55
    frame #7: 0x000000010011c7fd interactive_ui_tests`::SendKeyPressSync() + 77 at interactive_test_utils.cc:43
    frame #8: 0x00000001000daca3 interactive_ui_tests`::SendKeyForBrowser() + 51 at omnibox_view_browsertest.cc:185

from the assembly... it looks like maybe it wants a CGEvent, but we never put one on the synthetic event

    0x7fff9ec3f753 <+159>: movl   $0x6b6d6f64, %esi         ; imm = 0x6B6D6F64
    0x7fff9ec3f758 <+164>: movl   $0x6d61676e, %edx         ; imm = 0x6D61676E
    0x7fff9ec3f75d <+169>: movl   $0x4, %ecx
    0x7fff9ec3f762 <+174>: callq  0x7fff9f14f376            ; symbol stub for: SetEventParameter
    0x7fff9ec3f767 <+179>: movq   0x1b38907a(%rip), %rax    ; NSEvent._WSTimestamp
    0x7fff9ec3f76e <+186>: movq   (%r12,%rax), %rdx
    0x7fff9ec3f772 <+190>: movq   0x1b388fe7(%rip), %rcx    ; NSEventAuxiliary.cgEventRef
->  0x7fff9ec3f779 <+197>: cmpq   $0x0, (%rdx,%rcx)
    0x7fff9ec3f77e <+202>: je     0x7fff9ec3f790            ; <+220>

A fix for this might to modify cocoa_test_event_utils::SynthesizeKeyEvent() to wrap a CGEvent. But also it probably deserves a rdar

The other cool part: The actual test case that fails is "Cmd+Alt+v should NOT paste". Testing manually, in 10.11 it doesn't paste, but in 10.12 it does (without crashing). So the other part of the bug seems to be that this combo is matching the keyEquivalent when it shouldn't.

Similar stuff (i.e. keyEquivalents being triggered incorrectly with Alt pressed) happens in Sublime Text, but not Safari or iTerm, so this might be an SDK thing

If we just want the test to pass, something like https://codereview.chromium.org/2163153002/ will make this go away, but it's super gross. We should probably just wait for a fix from Apple. I'll nut out a repro and file a radar - a test app should trigger this -- it's probably a deployment target thing. But I don't think this needs to be a blocker.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Filed rdar://27541841 with the attached

Deleted: AltKeyEquivalentBug.zip 131 KB

AltKeyEquivalentBug.zip 131 KB Download

Deleted: interactive_ui_tests_2016-07-20-114710_Googles-Mac-Pro.crash 109 KB

interactive_ui_tests_2016-07-20-114710_Googles-Mac-Pro.crash 109 KB Download

I'm on Sierra now. I ran this and the test passes.

rdar://27541841 is still open, but Apple probably fixed it. Certainly, the stuff in #c4 no longer happens.