Here is how it works with MacViews off

Deleted: cocoa.mov 1.9 MB

	cocoa.mov 1.9 MB View Download

Thanks for filing this report.

(I think AppKit sends out a private notification for opening a mainMenu item, or manipulating a toolbar icon there - maybe to NSDistributedNotificationCenter rather than NSNotificaitonCenter - adding an observer with a nil object and NSLog ing it should let us see the name)

Able to reproduce this issue on Mac OS 10.13.3 on the latest Canary 69.0.3482.0 and Beta 68.0.3440.42 by enabling the flag #views-browser-windows.
Issue is not applicable to Windows 10 and Ubuntu 14.04.

Bisect Information:
===================
Good Build: 68.0.3431.0
Bad Build : 68.0.3432.0

By running the per-revision bisect script, float division by zero error was coming up. Hence below is the manual changelog URL from omahaproxy.

https://chromium.googlesource.com/chromium/src/+log/68.0.3431.0..68.0.3432.0?pretty=fuller&n=10000

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/1056468

spqchan@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.
Adding 'ReleaseBlock-Stable' label as this is a recent regression. Please feel free to remove if this is not applicable.

Thanks

We switched to Cocoa menus

There's still a bug here..  but lower-priority.

E.g. the `Folder` combobox dropdown on the Add Bookmark dialog should be dismissed when accessing the mainMenu bar.

Re comment 3, those notifications are not private.

The one I'd recommend is NSMenuDidBeginTrackingNotification (https://developer.apple.com/documentation/appkit/nsmenudidbegintrackingnotification) which is posted on [NSNotificationCenter defaultCenter]. That would be an easy one to watch for.

That actually wouldn't match Mac menus.

Mac menus capture any mouse click anywhere and eat it on dismissal. We'd need to install an event monitor to really do this right.

We do install an event monitor :)

Menus use Widget::SetCapture which instantiates a views::CocoaMouseCapture -- https://cs.chromium.org/chromium/src/ui/views/cocoa/cocoa_mouse_capture.h?q=CocoaMouseCapture&sq=package:chromium&g=0&l=24

It installs both a local and a global monitor for mouse events. Note clicks on other applications can not be eaten, but they do dismiss the menu. This is consistent with native menus.

I don't know why the monitors don't see the event that opens the mainMenu though :/

NSMenuDidBeginTrackingNotification might work. I think there's a special event that's specific to the mainMenu bar though, in case NSMenuDidBeginTrackingNotification isn't delivered (due to the mainMenu being out of process?). Or maybe that's just for clicking the wifi/battery/volume widgets that are up there (which also don't eat the event for native menus, just "observe" it).

I just found CocoaMouseCapture. Will investigate.

NSMenuDidBeginTrackingNotification totally works for the main menu. It doesn't work for the widgets, but we can mix in NSWindowDidResignKeyNotification and NSApplicationDidResignActiveNotification if needed.

Widgets are out of process, so a click on them triggers the global handler. No idea yet what is going on with clicks in the menu bar.

Menu bar clicks are

2018-07-30 20:25:44.237 Chromium[45253:11044646] local block event NSEvent: type=SysDefined loc=(1050,527) time=1654500.4 flags=0x100 win=0x0 winNum=0 ctxt=0x0 subtype=7 data1=1 data2=1

But this is really bizarre. I'm seeing SysDefined/7 events when I click the menu button, which makes little sense. And swallowing the SysDefined/7 events isn't preventing the menu showing.

I'm going to go with the simpler route of notifications.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a701a64a7cd935911eb1165ea3d124c0ccfc1db7

commit a701a64a7cd935911eb1165ea3d124c0ccfc1db7
Author: Avi Drissman <avi@chromium.org>
Date: Wed Aug 01 19:02:14 2018

Close Views menus when native menus are opened.

BUG= 859779 

Change-Id: I053e26086599ffb68f6379844bb20bf894e613e1
Reviewed-on: https://chromium-review.googlesource.com/1155663
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579881}
[modify] https://crrev.com/a701a64a7cd935911eb1165ea3d124c0ccfc1db7/ui/views/BUILD.gn
[add] https://crrev.com/a701a64a7cd935911eb1165ea3d124c0ccfc1db7/ui/views/controls/menu/menu_cocoa_watcher_mac.h
[add] https://crrev.com/a701a64a7cd935911eb1165ea3d124c0ccfc1db7/ui/views/controls/menu/menu_cocoa_watcher_mac.mm
[modify] https://crrev.com/a701a64a7cd935911eb1165ea3d124c0ccfc1db7/ui/views/controls/menu/menu_controller.cc
[modify] https://crrev.com/a701a64a7cd935911eb1165ea3d124c0ccfc1db7/ui/views/controls/menu/menu_controller.h

Able to reproduce the issue on Mac 10.12.6 on reported chrome version 68.0.3440.42.

Verified the fix on Mac 10.12.6, as per comment#0 on latest chrome version #70.0.3510.0.
Attaching screen cast for reference.
Observed that the context menu got dismissed when the menu bar is clicked.
Hence, the fix is working as expected.
Adding the verified labels.

Thanks...!!

Deleted: 859779.mp4 563 KB

	859779.mp4 563 KB View Download