Pls mark the bug as fixed if CL is landed in trunk and nothing else is pending. Thank you.

The short answer as to what's going on here:

Menus use a global event tap (via CocoaMouseCapture) to receive mouse events even when not over the menu. The reason we do this is so that clicking outside the menu will dismiss it, and so that menu items can be dragged out of the menu (I think).

The exact behavior of SetCapture() from Windows is odd: it only delivers events within the source window, *except* that if a mouse button was pressed within the source window, it keeps delivering events (including moves) until all buttons are released.

One potential short-term fix here would be to stop capturing mouse moves and only capture clicks. Unfortunately the menu mouse tracking doesn't seem to work without the mouse capture, which is puzzling - I would have thought these events would arrive anyway via the menu's BridgedContentView.

A longer-term fix would be to (in general) migrate MacViews to using tracking rects, one per view and created only when needed, to handle mouse events; this would require a bit of reworking of how events are dispatched to target views, though. I have a WIP CL for that here: <https://chromium-review.googlesource.com/c/chromium/src/+/1030840> but I think it needs more detailed design work, because getting events dispatched to the right views is tricky (maybe?) in the presence of overlapped views. I'll keep looking into that.

In any case, I'm going to WontFix this specific bug - it has no user-visible impact and is not fixable per se, but it's a symptom of a larger issue (MacViews mouse move dispatch being wacky, issue 837615).