Adding RB Label as this is a recent Regression. Please remove if not required.
Thank You.

 Issue 791483  has been merged into this issue.

rpise@,
Seems issue working as intended on latest canary-65.0.3309.0 on Mac 10.12.6 OS. Could you please check the same and update the bug accordingly.
Thanks..!

I just checked this on Chrome Mac 65.0.3310.0 and can still reproduce this. Turns out the duplicated bug in #c2 isn't actually a duplicate either, I didn't realise this was a Mac specific one.

With response to comment #3 :
Rechecked the above issue on Mac OS X(10.12.6,10.13.1) with latest canary chrome version : 65.0.3311.0 and the issue is still reproduced.Kindly refer attached screen cast for reference.

Deleted: Actual_video.mov 706 KB

Actual_video.mov 706 KB Download

It looks like this is a problem with how we ignore ink drop ripples on Mac. InkDropHostView's constructor sets |ink_drop_visible_opacity_| to 0 on platforms where ripples shouldn't be used, but this causes problems later on when animating the ink drop ripple to a ACTION_PENDING state. I think there's an assumption that the background colour of the ink drop highlight will be replaced by the ink drop ripple, but on Mac it just ends up looking like the highlight disappears when long-pressing on a button with ink drops enabled.

I'm not sure what the right fix for this should be, or even the intended behaviour - on Mac, the Cocoa equivalents of the toolbar buttons have a light grey on hover, then a dark grey on press, and retains that dark grey colour if the press becomes a long press. Maybe that should be the correct behaviour for ink drops as well?

+mohsen@ for ownership of all the ink drop files - do you have ideas on how to fix this?

Note you can also observe this behaviour on the 'x' buttons on dialogs, but it's more obvious on the profile button described in the bug description here.

Ping for mohsen@, have you had a chance to look at #c6?

I'm not very familiar with Mac's ink drop and highlight behavior. If I understand you correctly, the highlight gets hidden when the ripple kicks in. Is it possible that using AutoHighlightMode::SHOW_ON_RIPPLE highlight mode fixes the issue?

+cc ellyjones@ who I think added highlight for buttons on Mac and might have a better idea what's happening here.

FYI: Same happens when you click on the Certificate, Cookies and Site settings items on Security Chip PopUp. Is this intended or also a bug?

Ah, I think AutoHighlightMode::SHOW_ON_RIPPLE works! Thanks mohsen@ for your advice. I think we still need to provide some visual feedback once the user clicks the mouse button (even with SHOW_ON_RIPPLE the button looks the same as on hover), but I might leave this for a separate patch.

The initial fix is here: https://chromium-review.googlesource.com/c/chromium/src/+/896724

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

commit 9719e6fd16213f6ea9e99f81ef00a42b8af930b4
Author: Patti <patricialor@chromium.org>
Date: Tue Feb 06 01:45:00 2018

MacViews: Fix ink drop highlights disappearing on click.

On Mac, material design ripples are disabled. This causes a bug where the
highlight that shows up when a normally-ripple-enabled button is hovered
suddenly disappears when the button is clicked. This is especially noticeable on
long-pressing buttons, where there is no visual indicator to show the button is
still pressed, even when the mouse button is still being held down.

Fix by allowing the highlight to show on ripple on Mac.

Bug:  795224 
Change-Id: Ibc5a0cce4d50c3b4e6a77763ec50af264c1db2d0
Reviewed-on: https://chromium-review.googlesource.com/896724
Reviewed-by: Mohsen Izadi <mohsen@chromium.org>
Commit-Queue: Patti <patricialor@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534573}
[modify] https://crrev.com/9719e6fd16213f6ea9e99f81ef00a42b8af930b4/ui/views/animation/ink_drop_host_view.cc

Rechecked the above issue on Mac OS X(10.12.6,10.13.1) with latest canary chrome version : 66.0.3341.0 and the issue is fixed.Kindly refer attached screen cast for reference.

Deleted: Actual_video.mov 721 KB

	Actual_video.mov 721 KB View Download

Thanks rpise@ for verifying.

I'm leaving this bug open because there is remaining work to do - as described in #c6, on changing from hover to pressed states should probably cause the button ink drops to get darker.

I'm going to demote this to P2 for the follow-up work, for tracking purposes.

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

commit 95253d13cf28bfeb52e453aeb33beebe1bc43a28
Author: Patricia Lor <patricialor@chromium.org>
Date: Mon Mar 12 07:00:57 2018

MacViews: Make sure highlights are unaffected by the ripple ban on Mac.

r534573 fixed a bug where hover highlights would disappear when a
normally-ripple-enabled button was long-pressed by always showing the highlight
during the ripple animation (which is invisible on MacViews). However, this fix
also caused non-highlight enabled bubbles to start showing the default highlight
implementation, which looks like a transparent reddish square. Fix this by
allowing ink drop clients to set their AutoHighlightMode according to the
platform.

Bug:  809896 ,  795224 
Change-Id: I4e1269900c38b75affb7606b6eab5f034cd609d4
Reviewed-on: https://chromium-review.googlesource.com/930522
Reviewed-by: Trent Apted <tapted@chromium.org>
Reviewed-by: Mohsen Izadi <mohsen@chromium.org>
Commit-Queue: Patti <patricialor@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542433}
[modify] https://crrev.com/95253d13cf28bfeb52e453aeb33beebe1bc43a28/chrome/browser/ui/views/hover_button.cc
[modify] https://crrev.com/95253d13cf28bfeb52e453aeb33beebe1bc43a28/chrome/browser/ui/views/hover_button.h
[modify] https://crrev.com/95253d13cf28bfeb52e453aeb33beebe1bc43a28/ui/views/animation/ink_drop_host_view.cc
[modify] https://crrev.com/95253d13cf28bfeb52e453aeb33beebe1bc43a28/ui/views/animation/ink_drop_impl.cc
[modify] https://crrev.com/95253d13cf28bfeb52e453aeb33beebe1bc43a28/ui/views/animation/ink_drop_impl.h
[modify] https://crrev.com/95253d13cf28bfeb52e453aeb33beebe1bc43a28/ui/views/controls/button/button.cc

Update : 
Retested above issue on Mac(10.12.6, 10.13.1) OS using latest Canary #67.0.3370.0 and issue is fixed. Now, Focus highlight does not disappear after clicking and holding mouse pointer on profile name. Kindly review the attached screen-cast.

Thank you!

Deleted: Current_Result.mov 1.4 MB

	Current_Result.mov 1.4 MB View Download

MacViews triage: repurposing this bug for the remaining work described in #15. To lgrey@ for M68.

 Issue 811936  has been merged into this issue.

** Bulk Edit **

FYI: Starting 04/13 M68 will be in canary, M68 Dev promotion will be on 04/26.

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

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

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

macviews triage: still assigned to lgrey@

Hey lgrey@: Looks like this is fixed in  bug 848767 . Should be in one of the next Canary Mac Builds:

Buttons on Toolbar/Bookmarksbar/Omnibox have a darken pressed state now under MacViews and MdRefresh. 

Closing per above. Thanks, pbos@!