I believe the Views user menu is targeting M64 so marking RBB M-64.

Able to reproduce the issue on Mac 10.12.6 Using chrome reported version-64.0.3265.0 as per the above steps.

Manual bisect info:
-------------------
Good-64.0.3264.0 - Revision-515409
Bad-64.0.3265.0 - Revision-515780

Per revision bisect info:
-------------------------
You are probably looking for a change made after 515522 (known good), but no later than 515523 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
https://chromium.googlesource.com/chromium/src/+log/a63b2ddd636c62a3fe3f5e46c6c951e9fce23993..ff683d4c68b0505229fe56d1bd34e371f1758124

Possible suspect:
-----------------
https://chromium.googlesource.com/chromium/src/+/ff683d4c68b0505229fe56d1bd34e371f1758124

jlebel@, Could you please take a look and reassign to the right owner if it is not related to your change.

Note: Issue not seen on Linux & Windows OS

Thanks..!

This came up in review - Jerome had a partial workaround, but I didn't like it :)

I think this will be simple to handle if we simply change the machinery so that the menu appears on mousedown rather than mouseup. That is what menus should do on Mac.

It's also what the profile switcher _already_ does on Windows.

The problem currently is that the mousedown dismisses the dialog, so by the time the mouseup is seen, the machinery thinks it's been closed already. But this is easy to resolve my moving the trigger to mousedown.

Moving the trigger to mousedown SGTM. Alan or Joel - any concerns with that?

This is marked as Beta blocker and M-64 will be branched in ~1 week time. If possible, please plan the fix before branch point.

Thank you!

Mihai, I wouldn't view this as a Beta blocker. Do you think you'll have something in the next week?

This is the next bug on my list once I'm done with DICE work. I'll look at it this week or the next one.

 Issue 788209  has been merged into this issue.

msarda@,

As per C#11,could you please take a look into it as it is marked as beta blocker.
Thanks..!

Note: 
M-64 will be branched in next few days and would be good to have all the Beta blockers resolved before branch point.

CL is being submitted by the CQ as I'm writing this comment.

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

commit feec86d260eb2d97e31db29526be56a2a6a0209b
Author: Mihai Sardarescu <msarda@chromium.org>
Date: Mon Nov 27 09:53:08 2017

[mac] Open profile chooser bubble on mouse down.

This CL opens the profile chooser bubble on mouse down events as
suggested in https://bugs.chromium.org/p/chromium/issues/detail?id=784574#c5

Bug:  784574 
Change-Id: I267c59e0612e7030ebf50526109bf9f4d99d41df
Reviewed-on: https://chromium-review.googlesource.com/789111
Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: Mihai Sardarescu <msarda@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519259}
[modify] https://crrev.com/feec86d260eb2d97e31db29526be56a2a6a0209b/chrome/browser/ui/cocoa/profiles/avatar_button_controller.mm
[modify] https://crrev.com/feec86d260eb2d97e31db29526be56a2a6a0209b/ui/base/cocoa/hover_button.h
[modify] https://crrev.com/feec86d260eb2d97e31db29526be56a2a6a0209b/ui/base/cocoa/hover_button.mm

Tested this issue on Mac 10.12.6 using chrome latest Canary-64.0.3279.0	as per steps in C#0.

Observed that the user menu gets appeared once & disappeared upon clicking user button next time and so on.As this issue working as intended, adding TE verified labels.

Please find the attached screencast for reference.

Thanks..!

Deleted: 784574-Mac.mp4 620 KB

	784574-Mac.mp4 620 KB View Download

This seems to be fixed if there's a significant delay between clicks but the problem still exists for clicks less than ~1/2s apart.

Yes, here's a video showing how differently the Settings button and Profile button react to quick clicks.

Deleted: Settings_vs_Profile.mov 1.8 MB

Settings_vs_Profile.mov 1.8 MB Download

Mihai, are you going to take a look at this? Do you need any help?

This is working as expected right? Double-clicks on location bar decorations (padlock, bookmarks star, etc.) also do not immediately dismiss. The Chrome menu does. The menu on extension browser action buttons are different again. Popups on browser menu action buttons are, again, different. The menu shown on the back button is a fifth kind of different. (And the bookmarks bar, a sixth - although it's pretty close to the chrome menu apart from fade out).

If we want to change this it should be a separate bug. But I doubt that looking at the profile switcher for less than 500ms and expecting it to dismiss again on click is an interesting use case.

> This is working as expected right? Double-clicks on location bar decorations (padlock, bookmarks star, etc.) also do not immediately dismiss.

No, this is not working as expected, and the bookmarks star, for example, does dismiss immediately (perhaps you are looking at the Views version which seems to also suffer from this bug?).

In general, if clicking on some control summons a dialog, clicking again should dismiss it. If I click on a control and get a dialog, my intent in clicking the control a second time is never to keep it onscreen. I'm clicking it again because I didn't mean to click it in the first place or I just wanted to see what it brought up, and now I just want to get rid of it.

I've filed  Issue 789377  for the suppression of window [de]activation -- seems the macOS window server is what suppresses these events.

This particular issue is not fixed, and is a regression from the existing behavior.

Originally I thought the title of  Issue 789377  did not apply to this particular problem, so I was thinking closing this bug would mean this problem would be lost. I am going to make  Issue 789377  a blocker for this bug and elevate its priority, etc. If that's not the right plan for  Issue 789377  we can change its target milestone but either way this particular bug (784574) will remain a RBS for M64.

Jayson/Trent: It looks like all depending bugs are now closed? Is this bug still valid? Or can we close it now?

I'm waiting for tomorrow's Canary to confirm.

Looks like it's fixed - thank you tapted@!

[Auto-generated comment by a script] We noticed that this issue is targeted for M-64; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-64 label, otherwise remove Merge-TBD label. Thanks.