Placing it 1px lower would also match it with the height of the NSMenu that's shown for extensions without their own popup.

Please see the screenshot. Thanks :-)

Deleted: Bildschirmfoto 2018-01-09 um 18.14.55.png 35.8 KB

	Bildschirmfoto 2018-01-09 um 18.14.55.png 35.8 KB View Download

+bettes I think we want to tweak Windows as well? It currently anchors one pixel _lower_ than the bookmarks bubble.

(or do we want to shift Mac down two pixels?)

Deleted: win.png 64.1 KB

	win.png 64.1 KB View Download

Nice catch! I agree with c1 and yes, this applies to Windows as well. 

These Proj=MacViews bugs should probably be tracking for Phase 3 ( Issue 603386 ) - m66.

bsep: did you fix this at some point?

No, I haven't touched it. Do you want me to try to fix it for 67?

68 would be okay too, but 67 would be best :)

If we're targeting for M67, pls have the fix landed ASAP to trunk.

Delegating to pbos@

Observation: Mine's 1px lower than Bret's, so perhaps Bret's hit by HDPI inconsistency?

FWIW I think mine's fine and doesn't have to align with the bottom of the location bar. Bret's looks wonky because there's no visual spacing between the location-bar bottom and the bubble top so you get a 2px border effectively.

I'm not sure if the solution is to align Bret's with mine or align mine with the location bar? The placement is natural for location-bar items as the bubbles are associated with the location bar. bettes@ WDYT w/r/t this screenshot? I think it's fine and that the visual distinction between location bar and browser-action bubbles might even be useful?

Deleted: even-lower.png 10.3 KB

	even-lower.png 10.3 KB View Download

To be clear, bsep@'s screenshot looks egregious. :)

Bret set my mind straight. I think the inkdrop effect is inset from the icon edge, so as we're attaching to the icon it looks like it's not attaching to the visible bubble area (inkdrop area) as it's smaller than the button.

** Bulk Edit **

There are only two M67 dev releases left on 04/03 & 04/10 before M67 branch on 04/12. Please try to land the fix ASAP to trunk so we can move forward with 50%-50% experiment on M67 Canary/Dev (if possible at all). Thank you.

** Bulk Edit **

There is only one dev release left 04/10 before M67 branch on 04/12. Please try to land the fix ASAP to trunk so we can move forward with 50%-50% experiment on M67 Canary/Dev (if possible at all). Thank you.

FYI: Change/Fix has to be landed in trunk latest by 4:00 PM PT, Friday (04/06) so we can pick it up for next week dev release. 

Bumping major, feel free to take this bug from me if it's urgent.

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

Secondary UI - Moving to M70

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

commit 6f92518b820eb652ed4d03512728f1d032042a96
Author: Peter Boström <pbos@chromium.org>
Date: Wed Aug 01 18:12:37 2018

Use inset anchor bounds for toolbar buttons

Adds a Views::GetAnchorBoundsInScreen() method. This defaults to
GetBoundsInScreen() but can be overridden for views whose visual
bounds differ from their actual bounds. This is the case for toolbar
buttons on Touch (that provide larger hit targets than their visual
size).

This method is then used for the menus spawned by AppMenuButton and
ToolbarButton as well as BubbleDialogDelegate which allows these
specific menus and BubbleDialogDelegates in general to be better
aligned visually to their anchors.

Bug:  chromium:800372 , chromium:869928
Change-Id: I9c516d8a7ecb6c922e347d4db61ce1db72c71be7
Reviewed-on: https://chromium-review.googlesource.com/1152525
Commit-Queue: Peter Boström <pbos@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579861}
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/chrome/browser/ui/views/toolbar/app_menu.cc
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/chrome/browser/ui/views/toolbar/browser_app_menu_button.cc
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/chrome/browser/ui/views/toolbar/browser_app_menu_button.h
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/chrome/browser/ui/views/toolbar/toolbar_action_view.cc
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/chrome/browser/ui/views/toolbar/toolbar_action_view.h
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/chrome/browser/ui/views/toolbar/toolbar_button.cc
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/chrome/browser/ui/views/toolbar/toolbar_button.h
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/ui/views/bubble/bubble_dialog_delegate.cc
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/ui/views/bubble/bubble_dialog_delegate.h
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/ui/views/view.cc
[modify] https://crrev.com/6f92518b820eb652ed4d03512728f1d032042a96/ui/views/view.h

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

commit 1d1b230e8e6f2e18058273dec7d9b5770f3871db
Author: Peter Boström <pbos@chromium.org>
Date: Tue Oct 16 21:19:33 2018

Anchor ToolbarActionView context menu correctly

Makes ToolbarActionView::DoShowContextMenu use GetAnchorBoundsInScreen
which insets into the view to match the visible inkdrop hover effects.

Bug:  chromium:800372 
Change-Id: Ibe2bfe93547bae75590c87214e2c1ed0b73aa37b
Reviewed-on: https://chromium-review.googlesource.com/c/1281919
Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600124}
[modify] https://crrev.com/1d1b230e8e6f2e18058273dec7d9b5770f3871db/chrome/browser/ui/views/toolbar/toolbar_action_view.cc

Verified the fix on Mac 10.13.1, Windows-10 and Ubuntu 14.04 using Chrome version #72.0.3583.0 as per the comment #0.
Attaching screen shot for reference.
Observed the alignment of pop-up height is proper.
Hence, the fix is working as expected. 
Adding the verified labels.
Note: Able to reproduce the issue on chrome version with out fix.

Thanks...!!

Deleted: 800372.png 303 KB

	800372.png 303 KB View Download