Omnibox: https://chromium-review.googlesource.com/c/chromium/src/+/1014737

I suspect that the controls in question are only influenced by the "Appearance" setting, not the "Highlight color" setting, because they're menu components rather than what cocoa regards as a list? 

In any case, I'd like to remove our respect of the "Appearance" setting because the value to customize between Blue and Graphite is less compelling than the infinite colors available in the "Highlight" setting.  Highlight, not appearance, is routed to the safari search box so the experience already isn't 1:1. 

Expected design: 

If the hover effect needs to be transparent: #2A3146, 10%
https://docs.google.com/presentation/d/1EO7TOpIMJ7QHjaTVw9St-q6naKwtXX2TwzMirG5EsKY/edit#slide=id.g3232c09376_6_915

If the hover effect needs to be opaque: Google Grey 200 (#E8EAED)

#4: Okay - that is different than what we talked about a few days ago but fine with me.

Planned status then:
1) Menus will use the Aqua or Graphite hover color as appropriate - in Graphite mode they will use Grey 200, in Aqua mode they will use a blue of similar luminance and saturation (not sure exactly what yet).
2) The omnibox, page actions, and button hovers will use either #2A3146 10% or Grey 200 as appropriate regardless of Aqua/Graphite.

Does that sound good to you?

Also, for the record, I did some investigation/prototyping here:

Mac has "Appearance" (which is Aqua or Graphite) and "Highlight color" (which is an arbitrary user-chosen color).

In system apps and Safari, Appearance is used for:
* Menu selection
* Buttons / TabbedPanes / etc
* Focus rings

and Highlight is used for:
* Text selection
* Listbox selection

At the moment, Chrome Canary:
* Uses Appearance for menu selection
* Uses Appearance for buttons (i.e., Harmony buttons turn grey in Graphite mode)
* Uses Appearance for focus rings
* Uses Highlight for text selection
* Does *not* use Highlight for listbox selection (omnibox, task manager, etc)

I prototyped using Highlight for listbox selection, and after prototyping I do not think we should use it. It works well in Safari because their omnibox is extremely monochrome - it does not show favicons, stars, any decorations of any kind except for the top hit, and for the top hit the favicon often looks kind of bad for certain (website, highlight) combinations. Our omnibox has far more decorations in it so that problem would be much worse. Also, supporting arbitrary highlights here would significantly constrain our future freedom to experiment with the omnibox.

Thanks for the further investigation. I agree with your assessment around Highlight settings. I did the same and mapped what we currently honor and what we don't regarding Appearance:

* Menu selection (honored) 
* Buttons / TabbedPanes / etc .  (honored) 
* Focus rings (ignored) 
[new] * window controls (honored) 

Re: point 2 in c5, we have this matrix

* Menu selection (honored) 
* Buttons / TabbedPanes / etc .  (ignored) 
* Focus rings (ignored) 
* window controls (honored) 

Re: point 1 in c5, I'm actually proposing that we use Grey 200 (GG900,10%) for menus regardless of Aqua/Graphite settings. 

* Menu selection (ignored) 
* Buttons / TabbedPanes / etc .  (ignored) 
* Focus rings (ignored) 
* window controls (honored) 

This simplifies our design system and makes our specs for Views and MacViews identical. I agree that arbitrary settings can constrain our freedoms with future experiments, and I think the same applies to menus. Visually, I don't think we're asking too much from our users. We've trained them on grey highlights for years with the Omnibox. 

The contextual menu-emoji feature is a good example, where the visibility of our icon is obscured with the Appearance settings. This type of independence in our visual design spec allows for easier development in the future. 


>> 2) The omnibox, page actions, and button hovers will use either #2A3146 10% or Grey 200 as appropriate regardless of Aqua/Graphite.

*CORRECTION* Grey 200 or GG900,10% (not #2A3146)

Deleted: emoji_aqua.png 23.7 KB

	emoji_aqua.png 23.7 KB View Download

Deleted: emoji_graphite.png 23.8 KB

	emoji_graphite.png 23.8 KB View Download

*CORRECTION* Grey 200 or GG900,10% (not #2A3146)

https://docs.google.com/presentation/d/1EO7TOpIMJ7QHjaTVw9St-q6naKwtXX2TwzMirG5EsKY/edit#slide=id.g3232c09376_6_915

#7: okay, got it. So the only change from our current state is:

1) Change menu highlights back to always grey (just remove the Mac-specific code there)

I will implement this today.

https://chromium-review.googlesource.com/c/chromium/src/+/1023318 changes the highlights to GoogleGrey200.

By the way, is there a canonical source of these various color constants?

Yes, absolutely. Tear sheet available at go/chrome-ux-gm2-core. 

The views team is setting Google Grey 900 as the base color, replacing pure black. With that, the spectrum of Google Greys can be achieved through various opacities of GG900. Let me know how you decide to proceed with this, and/or if you plan on doing something different. 

Deleted: chrome-colors.png 438 KB

	chrome-colors.png 438 KB View Download

GoogleGrey200 works fine for me, so I'm using that in the linke dCL.

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

commit 29588c13021f97d8af2dd3e7444ca3e064cddd3a
Author: Elly Fong-Jones <ellyjones@chromium.org>
Date: Wed Apr 25 15:24:59 2018

macviews: change menu highlights back to plain grey

We experimented with following the system highlight, but it doesn't look
good in menus with icons. See the linked bug for discussion & rationale.

Bug:  829467 
Change-Id: Ie3f5e74b17c5ec9956b0501582dfeef838fcc673
Reviewed-on: https://chromium-review.googlesource.com/1023318
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553565}
[modify] https://crrev.com/29588c13021f97d8af2dd3e7444ca3e064cddd3a/ui/gfx/color_palette.h
[modify] https://crrev.com/29588c13021f97d8af2dd3e7444ca3e064cddd3a/ui/native_theme/native_theme_mac.mm

Able to reproduce the bug on build without fix(68.0.3400.0) hence verifying the fix on latest canary 68.0.3409.0

1. Enabled chrome://flags/#views-browser-windows and chrome://flags/#enable-emoji-context-menu flags from chrome://flags
2. Now in Temperance selected Blue/Grey and observed hover highlight as Blue/Grey respectively. Adding screen cast for reference.

@ellyjones: Could you please check the screencast and let us know if we followed same steps or not. Also please help in verifying the fix.

Thanks!

Deleted: 829467.mp4 1.8 MB

	829467.mp4 1.8 MB View Download

#15: that context menu is not a Views menu - try the App menu instead (the three-dots menu).

 Issue 836958  has been merged into this issue.

Able to reproduce the bug on build without fix(68.0.3400.0) hence verifying the fix on latest canary 68.0.3410.0.

On selecting Graphite/Blue view menu hover is seen grey. Attaching screencast for reference.

As fix is working as intended adding TE-Verified labels.

Thanks!

Deleted: 829467(1).mp4 1.1 MB

	829467(1).mp4 1.1 MB View Download