blending with FFF seems right. Assuming that's how a disabled forward arrow is rendered? The outcome should just mimic how we treated it in stable.

Mocks: 
https://gallery.googleplex.com/projects/MCHbtQVoQ2HCZW9TjXpqhOa9/files/MCGzOAHDM-CKDhphdtwffZIOwMSJbxAVNpw


Windows proposal for inactive window treatment is different: https://bugs.chromium.org/p/chromium/issues/detail?id=859243#c7 

Deleted: v2 - default MacOS.png 297 KB

	v2 - default MacOS.png 297 KB View Download

Thanks for the mocks. We'll target this for M70.

Upgrading to P2 based off of design Post M69 triage.

Is the guidance here to only change the visuals, not the actual behavior? If so, the end result is a button that looks exactly like other disabled buttons, but still activates on click. Isn't that visually inconsistent, leading to user confusion?

#14: Hmmm, that is a good point. Native Mac apps do not behave that way - rather, an inactive window's controls appear dimmed and a click on the window serves to activate the window but *not* activate the controls. In light of that, the CL I put up is wrong and instead I should have Button subclasses (or maybe all Views?) change their enabled state when the widget becomes inactive.

Elly, disabling when inactive for only mac SGTM.

Ick. I just re-tested, and I was wrong about the general behavior on Mac. Some kinds of controls, like Safari's bookmark tray, are not activated on click of a background window, but most controls (including generic buttons, textfields, etc) are activated on click of a background window, so I think we *do* need the behavior described in #14, and not just for buttons, either. Sorry for the confusion.

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

commit 821bb5d7ee96d2ce476850875e3a6459a5528d64
Author: Elly Fong-Jones <ellyjones@chromium.org>
Date: Wed Oct 17 17:58:44 2018

views: fade buttons in inactive widgets

This change:
1) Adds an inner WidgetObserver subclass to Button to allow Button to observe
   its Widget's activation state changing;
2) Introduces a notion of "visual state" to buttons, as distinct from their
   existing state; the visual state governs how a button is drawn.
3) Has LabelButton use the visual state to decide which image to use instead
   of the raw state.

The end result is that when a LabelButton's Widget deactivates, that LabelButton
will take on a disabled appearance.

Bug: 848593
Change-Id: If5bd135c254fd36669e76fd39338dc24387602aa
Reviewed-on: https://chromium-review.googlesource.com/c/1251330
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600471}
[modify] https://crrev.com/821bb5d7ee96d2ce476850875e3a6459a5528d64/ui/views/controls/button/button.cc
[modify] https://crrev.com/821bb5d7ee96d2ce476850875e3a6459a5528d64/ui/views/controls/button/button.h
[modify] https://crrev.com/821bb5d7ee96d2ce476850875e3a6459a5528d64/ui/views/controls/button/label_button.cc
[modify] https://crrev.com/821bb5d7ee96d2ce476850875e3a6459a5528d64/ui/views/style/platform_style.cc
[modify] https://crrev.com/821bb5d7ee96d2ce476850875e3a6459a5528d64/ui/views/style/platform_style.h
[modify] https://crrev.com/821bb5d7ee96d2ce476850875e3a6459a5528d64/ui/views/style/platform_style_mac.mm

I'm consulting with UX about whether this is done or whether we want to do other controls as well.

Followed up with UX:

1) Tab controls should dim to 0.7a or something (maybe the current 0.28a white blend is okay)
2) Extension icons should dim also

Hi, I noticed the following. May be it is already on your agenda :)

1.) Focus the text/address in the Omnibox, so that it is blue highlighted.
2.) Unfocus the window by clicking on the Desktop.

Actual: Highlight isn't to see.

Expected: Highlight should be change to grey and still visible.

That is the way it is working when you focussing some text in the web content. Safari's Address Bar also handling it that way.

Thanks :)

Authoritative spec doc (internal only): <https://docs.google.com/spreadsheets/d/1-bWPo3G-QwkYTSKJkLutvYaqf3UmOdUETku0WbUyUWc/edit#gid=0>

Mass UI Triage 

Just to update:
We were unable to reproduce this bug on latest canary #72.0.3618.0 on Mac(10.13.1, 10.13.4,10.14.2), OS.


Thank you.

re#23: Not sure, if this is completely done? See c#20 (and c#21).

Back to assigned. ellyjones@: Feel free to close the report, if you think everything is done here. Thanks.

Correct, this is not yet fixed because the specs in #22 are not yet fully implemented.