Moved --top-chrome-md command line switch from chrome_switches to ui_base_switches.

Moved --top-chrome-md command line switch from chrome_switches to ui_base_switches.

The switch needed to be accessible from ui/base/resources for loading the different assets.
Also defined the ENABLE_TOPCHROME_MD compile time switch on linux builds.

TEST=MaterialDesignControllerTest.NonMaterialModeWhenCompileTimeFlagDisabled
TEST=MaterialDesignControllerTest.EnabledCommandLineValueMapsToMaterialModeWhenCompileTimeFlagEnabled
TEST=MaterialDesignControllerTest.EnabledHybridCommandLineValueMapsToMaterialHybridModeWhenCompileTimeFlagEnabled
TEST=MaterialDesignControllerTest.DisabledCommandLineValueMapsToNonMaterialModeWhenCompileTimeFlagEnabled
TEST=MaterialDesignControllerTest.NoCommandLineValueMapsToNonMaterialModeWhenCompileTimeFlagEnabled
TEST=MaterialDesignControllerTest.InvalidCommandLineValueFails

BUG=501366
Committed: https://crrev.com/0d89d6ac4a77feaa44da9cb4abb456ca800981b4
Cr-Commit-Position: refs/heads/master@{#336442}

[bruthig, 2015-06-18 19:47:26]

bruthig@chromium.org changed reviewers:
+ girard@chromium.org, jonross@chromium.org, tdanderson@chromium.org

[bruthig, 2015-06-18 19:47:26]

girard@, jonross@, tdanderson@:

Can you guys take a look at the MaterialDesignController::GetLookAndFeel()
function to make sure it will meet our needs?

girard@:

Can you have a look at everything to make sure I haven't overlooked something
with the switches?

[girard, 2015-06-18 19:58:38]

On 2015/06/18 19:47:26, bruthig wrote:
> girard@, jonross@, tdanderson@:
> 
> Can you guys take a look at the MaterialDesignController::GetLookAndFeel()
> function to make sure it will meet our needs?
> 
> girard@:
> 
> Can you have a look at everything to make sure I haven't overlooked something
> with the switches?

I'm a little uncomfortable with "GetLookAndFeel" because of grammatical
reasons;) I guess the traditional MVC pattern tries to separate look (View) from
feel (Controller), or maybe it's the use of "And".

I think Mode might be a better term for this.

[flackr, 2015-06-18 20:50:58]

https://codereview.chromium.org/1188713007/diff/1/chrome/browser/about_flags.cc
File chrome/browser/about_flags.cc (right):

https://codereview.chromium.org/1188713007/diff/1/chrome/browser/about_flags....
chrome/browser/about_flags.cc:431: {IDS_GENERIC_EXPERIMENT_CHOICE_DEFAULT, "",
""},
Unless/until we make this an experiment where default is unknown, I think we
should not have an option labeled default but instead make the default option
the one which passes no flags.

When https://codereview.chromium.org/1191493004/ lands this option will have the
same formatting as unchanged regular switches when in its default value.

[tdanderson, 2015-06-18 20:54:24]

Ben, please see my comments below.

https://codereview.chromium.org/1188713007/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/1188713007/diff/1/build/common.gypi#newcode2
build/common.gypi:2: # Use of this source code is governed by a BSD-style
license that can be
I just noticed a mistake in build/config/BUILD.gn landed along with
https://codereview.chromium.org/1108333002 (ENABLE_TOPCHRME_MD=1 is missing the
O). Can you please take a look and address in this CL?

https://codereview.chromium.org/1188713007/diff/1/build/common.gypi#newcode233
build/common.gypi:233: # Enable Top Chrome Material Design on Chrome OS, and
Windows.
update comment to include Linux

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
File ui/base/material_design/material_design_controller.cc (right):

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
ui/base/material_design/material_design_controller.cc:43: NOTREACHED();
Consider including a message here (NOTREACHED() << "...")

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
File ui/base/material_design/material_design_controller.h (right):

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
ui/base/material_design/material_design_controller.h:21: enum class LookAndFeel
{
+1 to Gene's suggestion of using "mode" instead of "look and feel" throughout
this CL.

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
ui/base/material_design/material_design_controller.h:24: // Material design look
and feel targeted for convertible devices.
I'd re-phrase the comment here (and in ui_base_switches.cc) to say "hybrid
mouse/touch devices" rather than "convertible devices".

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
ui/base/material_design/material_design_controller.h:27: CLASSIC
Naming these MATERIAL, MATERIAL_HYBRID, and NON_MATERIAL may be better for
readability.

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
ui/base/material_design/material_design_controller.h:37: static bool
is_look_and_feel_initialized_;
Perhaps include a comment about why this is needed? (I think you told me this is
necessary to be able to test?)

https://codereview.chromium.org/1188713007/diff/1/ui/base/ui_base_switches.h
File ui/base/ui_base_switches.h (right):

https://codereview.chromium.org/1188713007/diff/1/ui/base/ui_base_switches.h#...
ui/base/ui_base_switches.h:33: #ifdef ENABLE_TOPCHROME_MD
nit: use #if defined(...) for consistency within the file? (here and within
ui_base_switches.cc)

[bruthig, 2015-06-22 18:51:12]

Hey all,

I've addressed all the comments from patch set 1.  Can you please have another
look?

https://codereview.chromium.org/1188713007/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/1188713007/diff/1/build/common.gypi#newcode233
build/common.gypi:233: # Enable Top Chrome Material Design on Chrome OS, and
Windows.
On 2015/06/18 20:54:23, tdanderson wrote:
> update comment to include Linux

Done.

https://codereview.chromium.org/1188713007/diff/1/chrome/browser/about_flags.cc
File chrome/browser/about_flags.cc (right):

https://codereview.chromium.org/1188713007/diff/1/chrome/browser/about_flags....
chrome/browser/about_flags.cc:431: {IDS_GENERIC_EXPERIMENT_CHOICE_DEFAULT, "",
""},
On 2015/06/18 20:50:58, flackr wrote:
> Unless/until we make this an experiment where default is unknown, I think we
> should not have an option labeled default but instead make the default option
> the one which passes no flags.
> 
> When https://codereview.chromium.org/1191493004/ lands this option will have
the
> same formatting as unchanged regular switches when in its default value.

Done.

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
File ui/base/material_design/material_design_controller.cc (right):

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
ui/base/material_design/material_design_controller.cc:43: NOTREACHED();
On 2015/06/18 20:54:23, tdanderson wrote:
> Consider including a message here (NOTREACHED() << "...")

Done.

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
File ui/base/material_design/material_design_controller.h (right):

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
ui/base/material_design/material_design_controller.h:21: enum class LookAndFeel
{
On 2015/06/18 20:54:23, tdanderson wrote:
> +1 to Gene's suggestion of using "mode" instead of "look and feel" throughout
> this CL.

Done.

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
ui/base/material_design/material_design_controller.h:24: // Material design look
and feel targeted for convertible devices.
On 2015/06/18 20:54:23, tdanderson wrote:
> I'd re-phrase the comment here (and in ui_base_switches.cc) to say "hybrid
> mouse/touch devices" rather than "convertible devices".

Done.

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
ui/base/material_design/material_design_controller.h:27: CLASSIC
On 2015/06/18 20:54:24, tdanderson wrote:
> Naming these MATERIAL, MATERIAL_HYBRID, and NON_MATERIAL may be better for
> readability.

Done.

https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
ui/base/material_design/material_design_controller.h:37: static bool
is_look_and_feel_initialized_;
On 2015/06/18 20:54:23, tdanderson wrote:
> Perhaps include a comment about why this is needed? (I think you told me this
is
> necessary to be able to test?)

Done.

https://codereview.chromium.org/1188713007/diff/1/ui/base/ui_base_switches.h
File ui/base/ui_base_switches.h (right):

https://codereview.chromium.org/1188713007/diff/1/ui/base/ui_base_switches.h#...
ui/base/ui_base_switches.h:33: #ifdef ENABLE_TOPCHROME_MD
On 2015/06/18 20:54:24, tdanderson wrote:
> nit: use #if defined(...) for consistency within the file? (here and within
> ui_base_switches.cc)

Done.

[jonross, 2015-06-22 20:39:11]

On 2015/06/22 18:51:12, bruthig wrote:
> Hey all,
> 
> I've addressed all the comments from patch set 1.  Can you please have another
> look?
> 
> https://codereview.chromium.org/1188713007/diff/1/build/common.gypi
> File build/common.gypi (right):
> 
> https://codereview.chromium.org/1188713007/diff/1/build/common.gypi#newcode233
> build/common.gypi:233: # Enable Top Chrome Material Design on Chrome OS, and
> Windows.
> On 2015/06/18 20:54:23, tdanderson wrote:
> > update comment to include Linux
> 
> Done.
> 
>
https://codereview.chromium.org/1188713007/diff/1/chrome/browser/about_flags.cc
> File chrome/browser/about_flags.cc (right):
> 
>
https://codereview.chromium.org/1188713007/diff/1/chrome/browser/about_flags....
> chrome/browser/about_flags.cc:431: {IDS_GENERIC_EXPERIMENT_CHOICE_DEFAULT, "",
> ""},
> On 2015/06/18 20:50:58, flackr wrote:
> > Unless/until we make this an experiment where default is unknown, I think we
> > should not have an option labeled default but instead make the default
option
> > the one which passes no flags.
> > 
> > When https://codereview.chromium.org/1191493004/ lands this option will have
> the
> > same formatting as unchanged regular switches when in its default value.
> 
> Done.
> 
>
https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
> File ui/base/material_design/material_design_controller.cc (right):
> 
>
https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
> ui/base/material_design/material_design_controller.cc:43: NOTREACHED();
> On 2015/06/18 20:54:23, tdanderson wrote:
> > Consider including a message here (NOTREACHED() << "...")
> 
> Done.
> 
>
https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
> File ui/base/material_design/material_design_controller.h (right):
> 
>
https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
> ui/base/material_design/material_design_controller.h:21: enum class
LookAndFeel
> {
> On 2015/06/18 20:54:23, tdanderson wrote:
> > +1 to Gene's suggestion of using "mode" instead of "look and feel"
throughout
> > this CL.
> 
> Done.
> 
>
https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
> ui/base/material_design/material_design_controller.h:24: // Material design
look
> and feel targeted for convertible devices.
> On 2015/06/18 20:54:23, tdanderson wrote:
> > I'd re-phrase the comment here (and in ui_base_switches.cc) to say "hybrid
> > mouse/touch devices" rather than "convertible devices".
> 
> Done.
> 
>
https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
> ui/base/material_design/material_design_controller.h:27: CLASSIC
> On 2015/06/18 20:54:24, tdanderson wrote:
> > Naming these MATERIAL, MATERIAL_HYBRID, and NON_MATERIAL may be better for
> > readability.
> 
> Done.
> 
>
https://codereview.chromium.org/1188713007/diff/1/ui/base/material_design/mat...
> ui/base/material_design/material_design_controller.h:37: static bool
> is_look_and_feel_initialized_;
> On 2015/06/18 20:54:23, tdanderson wrote:
> > Perhaps include a comment about why this is needed? (I think you told me
this
> is
> > necessary to be able to test?)
> 
> Done.
> 
> https://codereview.chromium.org/1188713007/diff/1/ui/base/ui_base_switches.h
> File ui/base/ui_base_switches.h (right):
> 
>
https://codereview.chromium.org/1188713007/diff/1/ui/base/ui_base_switches.h#...
> ui/base/ui_base_switches.h:33: #ifdef ENABLE_TOPCHROME_MD
> On 2015/06/18 20:54:24, tdanderson wrote:
> > nit: use #if defined(...) for consistency within the file? (here and within
> > ui_base_switches.cc)
> 
> Done.

LGTM

[tdanderson, 2015-06-22 20:59:44]

lgtm with a grammar nit

https://codereview.chromium.org/1188713007/diff/40001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1188713007/diff/40001/chrome/app/generated_re...
chrome/app/generated_resources.grd:5685: +        Set's the material design
elements in the browser's top chrome.
Set's -> Sets

[bruthig, 2015-06-22 21:05:56]

bruthig@chromium.org changed reviewers:
+ asvitkine@chromium.org, cpu@chromium.org

[bruthig, 2015-06-22 21:05:56]

asvitkine@chromium.org: Please review changes in
 - histograms.xml

cpu@chromium.org: Please review changes in 
 - build/*
 - chrome/*
 - ui/*

[Alexei Svitkine (slow), 2015-06-22 21:10:05]

histograms lgtm

[cpu_(ooo_6.6-7.5), 2015-06-23 00:53:11]

please add an owner for /ui , the rest I can do.

[bruthig, 2015-06-23 14:02:35]

bruthig@chromium.org changed reviewers:
+ sadrul@chromium.org

[bruthig, 2015-06-23 14:02:35]

sadrul@, can you please review:
 - ui/*

[cpu_(ooo_6.6-7.5), 2015-06-23 17:41:42]

lgtm for chrome/* and build/*

https://codereview.chromium.org/1188713007/diff/40001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1188713007/diff/40001/chrome/app/generated_re...
chrome/app/generated_resources.grd:5685: +        Set's the material design
elements in the browser's top chrome.
On 2015/06/22 20:59:44, tdanderson wrote:
> Set's -> Sets

still not fixed

[sadrul, 2015-06-24 18:18:08]

A couple of questions about where material_design should live. It's fine where
it is right now, but there may be a better place for it, depending on how we
expect it to evolve.

https://codereview.chromium.org/1188713007/diff/40001/ui/base/material_design...
File ui/base/material_design/material_design_controller.h (right):

https://codereview.chromium.org/1188713007/diff/40001/ui/base/material_design...
ui/base/material_design/material_design_controller.h:18: class UI_BASE_EXPORT
MaterialDesignController {
. Do you expect to add more to MaterialDesignController (or to
//ui/base/material_design/)? i.e. would it make sense for it to be a separate
component if it's going to do a lot of work?

. If not, would it make sense for this to live in
//ui/base/resource/material_design/?

[jonross, 2015-06-24 18:33:01]

https://codereview.chromium.org/1188713007/diff/40001/ui/base/material_design...
File ui/base/material_design/material_design_controller.h (right):

https://codereview.chromium.org/1188713007/diff/40001/ui/base/material_design...
ui/base/material_design/material_design_controller.h:18: class UI_BASE_EXPORT
MaterialDesignController {
On 2015/06/24 18:18:08, sadrul wrote:
> . Do you expect to add more to MaterialDesignController (or to
> //ui/base/material_design/)? i.e. would it make sense for it to be a separate
> component if it's going to do a lot of work?
> 
> . If not, would it make sense for this to live in
> //ui/base/resource/material_design/?

In the future there is likely to be a reduction of MaterialDesignController. As
we do away with classic.

Depending on UI review there could be a point where the two material modes
become one, and this class can be removed entirely.

Though I can't rule out future UX decisions that could expand this class.

[bruthig, 2015-06-24 21:36:24]

I've moved the MaterialDesignController to  ui/base/resource/material_design/.

sadrul@, can you have another look at
 - ui/*

https://codereview.chromium.org/1188713007/diff/40001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1188713007/diff/40001/chrome/app/generated_re...
chrome/app/generated_resources.grd:5685: +        Set's the material design
elements in the browser's top chrome.
On 2015/06/23 17:41:42, cpu wrote:
> On 2015/06/22 20:59:44, tdanderson wrote:
> > Set's -> Sets
> 
> still not fixed

Done.

https://codereview.chromium.org/1188713007/diff/40001/ui/base/material_design...
File ui/base/material_design/material_design_controller.h (right):

https://codereview.chromium.org/1188713007/diff/40001/ui/base/material_design...
ui/base/material_design/material_design_controller.h:18: class UI_BASE_EXPORT
MaterialDesignController {
Done. Moved to //ui/base/resource/material_design

[Dan Beam, 2015-06-24 21:55:09]

dbeam@chromium.org changed reviewers:
+ dbeam@chromium.org

[Dan Beam, 2015-06-24 21:55:10]

https://codereview.chromium.org/1188713007/diff/60001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1188713007/diff/60001/chrome/app/generated_re...
chrome/app/generated_resources.grd:5685: +        Sets the material design
elements in the browser's top chrome.
how is this different from IDS_FLAGS_TOP_CHROME_MD?

https://codereview.chromium.org/1188713007/diff/60001/ui/base/ui_base_switches.h
File ui/base/ui_base_switches.h (right):

https://codereview.chromium.org/1188713007/diff/60001/ui/base/ui_base_switche...
ui/base/ui_base_switches.h:37: UI_BASE_EXPORT extern const char
kTopChromeMDNonMaterial[];
I'm trying to combine MD-related flags.  Why do we need 4 for this?

[tdanderson, 2015-06-25 16:48:48]

https://codereview.chromium.org/1188713007/diff/60001/ui/base/ui_base_switches.h
File ui/base/ui_base_switches.h (right):

https://codereview.chromium.org/1188713007/diff/60001/ui/base/ui_base_switche...
ui/base/ui_base_switches.h:37: UI_BASE_EXPORT extern const char
kTopChromeMDNonMaterial[];
On 2015/06/24 21:55:10, Dan Beam wrote:
> I'm trying to combine MD-related flags.  Why do we need 4 for this?

As discussed offline, this is needed for our use case of switching between
non-material, material, and hybrid layouts at runtime.

[Dan Beam, 2015-06-25 17:05:36]

https://codereview.chromium.org/1188713007/diff/60001/ui/base/ui_base_switches.h
File ui/base/ui_base_switches.h (right):

https://codereview.chromium.org/1188713007/diff/60001/ui/base/ui_base_switche...
ui/base/ui_base_switches.h:37: UI_BASE_EXPORT extern const char
kTopChromeMDNonMaterial[];
On 2015/06/25 16:48:48, tdanderson wrote:
> On 2015/06/24 21:55:10, Dan Beam wrote:
> > I'm trying to combine MD-related flags.  Why do we need 4 for this?
> 
> As discussed offline, this is needed for our use case of switching between
> non-material, material, and hybrid layouts at runtime.

Yeah, I understand now why you need them.  Do you think we could add doc
comments here explaining the differences?  I think having 4 flags with the same
prefix is kind of uncommon.  This I arguably an easier spot than in some far
away .grd after finding which IDS_* that corresponds to which flag (if those
even exist for this).

[bruthig, 2015-06-25 17:49:49]

https://codereview.chromium.org/1188713007/diff/60001/ui/base/ui_base_switches.h
File ui/base/ui_base_switches.h (right):

https://codereview.chromium.org/1188713007/diff/60001/ui/base/ui_base_switche...
ui/base/ui_base_switches.h:37: UI_BASE_EXPORT extern const char
kTopChromeMDNonMaterial[];
On 2015/06/25 17:05:35, Dan Beam wrote:
> On 2015/06/25 16:48:48, tdanderson wrote:
> > On 2015/06/24 21:55:10, Dan Beam wrote:
> > > I'm trying to combine MD-related flags.  Why do we need 4 for this?
> > 
> > As discussed offline, this is needed for our use case of switching between
> > non-material, material, and hybrid layouts at runtime.
> 
> Yeah, I understand now why you need them.  Do you think we could add doc
> comments here explaining the differences?  I think having 4 flags with the
same
> prefix is kind of uncommon.  This I arguably an easier spot than in some far
> away .grd after finding which IDS_* that corresponds to which flag (if those
> even exist for this).

As is the convention for these switches, the documentation is in the .cc file.

As for having switches having the same prefix, this may not seem common when
looking at the different *_switches.h files because most aren't of the
MULTI_VALUE_TYPE.  I took a look at the different Experiment::Choice arrays in
about_flags.cc and some examples of this convention are: kTouchEventsChoices,
kMarkNonSecureAsChoices, kExtensionContentVerificationChoices,
kExtensionContentVerificationChoices.

I'm open to suggestions but I feel like it is currently following conventions.

[Dan Beam, 2015-06-25 18:09:25]

dbeam@chromium.org changed reviewers:
- dbeam@chromium.org

[Dan Beam, 2015-06-25 18:11:43]

https://codereview.chromium.org/1188713007/diff/60001/ui/base/ui_base_switches.h
File ui/base/ui_base_switches.h (right):

https://codereview.chromium.org/1188713007/diff/60001/ui/base/ui_base_switche...
ui/base/ui_base_switches.h:37: UI_BASE_EXPORT extern const char
kTopChromeMDNonMaterial[];
On 2015/06/25 17:49:49, bruthig wrote:
> On 2015/06/25 17:05:35, Dan Beam wrote:
> > On 2015/06/25 16:48:48, tdanderson wrote:
> > > On 2015/06/24 21:55:10, Dan Beam wrote:
> > > > I'm trying to combine MD-related flags.  Why do we need 4 for this?
> > > 
> > > As discussed offline, this is needed for our use case of switching between
> > > non-material, material, and hybrid layouts at runtime.
> > 
> > Yeah, I understand now why you need them.  Do you think we could add doc
> > comments here explaining the differences?  I think having 4 flags with the
> same
> > prefix is kind of uncommon.  This I arguably an easier spot than in some far
> > away .grd after finding which IDS_* that corresponds to which flag (if those
> > even exist for this).
> 
> As is the convention for these switches, the documentation is in the .cc file.
> 
> As for having switches having the same prefix, this may not seem common when
> looking at the different *_switches.h files because most aren't of the
> MULTI_VALUE_TYPE.  I took a look at the different Experiment::Choice arrays in
> about_flags.cc and some examples of this convention are: kTouchEventsChoices,
> kMarkNonSecureAsChoices, kExtensionContentVerificationChoices,
> kExtensionContentVerificationChoices.
> 
> I'm open to suggestions but I feel like it is currently following conventions.

you're right and I just probably haven't seen that many MULTI_VALUE_TYPE.  good
enough for me, sorry for the noise.

https://codereview.chromium.org/1188713007/diff/80001/ui/base/ui_base_switches.h
File ui/base/ui_base_switches.h (right):

https://codereview.chromium.org/1188713007/diff/80001/ui/base/ui_base_switche...
ui/base/ui_base_switches.h:38: #endif  // defind(ENABLE_TOPCHROME_MD)
nit: defined

[sadrul, 2015-06-25 19:55:32]

lgtm

[bruthig, 2015-06-25 20:12:17]

The CQ bit was checked by bruthig@chromium.org

[bruthig, 2015-06-25 20:12:18]

The patchset sent to the CQ was uploaded after l-g-t-m from
tdanderson@chromium.org, cpu@chromium.org, jonross@chromium.org,
asvitkine@chromium.org
Link to the patchset: https://codereview.chromium.org/1188713007/#ps100001
(title: "Minor nit fixes and reverted typo fix in build/config/BUILD.gn")

[commit-bot: I haz the power, 2015-06-25 20:13:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1188713007/100001

[commit-bot: I haz the power, 2015-06-25 21:03:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-25 21:03:45]

Exceeded global retry quota

[bruthig, 2015-06-25 22:02:15]

The CQ bit was checked by bruthig@chromium.org

[bruthig, 2015-06-25 22:02:16]

The patchset sent to the CQ was uploaded after l-g-t-m from sadrul@chromium.org,
tdanderson@chromium.org, cpu@chromium.org, jonross@chromium.org,
asvitkine@chromium.org
Link to the patchset: https://codereview.chromium.org/1188713007/#ps120001
(title: "Added LoginCustomFlags enum entry and removed UI_BASE_EXPORT from
TestAPI.")

[commit-bot: I haz the power, 2015-06-25 22:02:45]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1188713007/120001

[commit-bot: I haz the power, 2015-06-26 01:10:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-26 01:10:49]

Try jobs failed on following builders:
  linux_chromium_gn_rel on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[bruthig, 2015-06-26 14:40:11]

The CQ bit was checked by bruthig@chromium.org

[bruthig, 2015-06-26 14:40:11]

The patchset sent to the CQ was uploaded after l-g-t-m from sadrul@chromium.org,
tdanderson@chromium.org, cpu@chromium.org, jonross@chromium.org,
asvitkine@chromium.org
Link to the patchset: https://codereview.chromium.org/1188713007/#ps140001
(title: "Added guards to a death test so it is not run on a release build.")

[commit-bot: I haz the power, 2015-06-26 14:40:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1188713007/140001

[commit-bot: I haz the power, 2015-06-26 15:15:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-26 15:15:53]

Exceeded global retry quota

[bruthig, 2015-06-26 16:05:33]

The CQ bit was checked by bruthig@chromium.org

[bruthig, 2015-06-26 16:05:34]

The patchset sent to the CQ was uploaded after l-g-t-m from sadrul@chromium.org,
tdanderson@chromium.org, cpu@chromium.org, jonross@chromium.org,
asvitkine@chromium.org
Link to the patchset: https://codereview.chromium.org/1188713007/#ps160001
(title: "Removed 'typename' from typedef.")

[commit-bot: I haz the power, 2015-06-26 16:06:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1188713007/160001

[commit-bot: I haz the power, 2015-06-26 16:31:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-26 16:31:17]

Exceeded global retry quota

[bruthig, 2015-06-26 17:37:48]

The CQ bit was checked by bruthig@chromium.org

[bruthig, 2015-06-26 17:37:49]

The patchset sent to the CQ was uploaded after l-g-t-m from sadrul@chromium.org,
tdanderson@chromium.org, cpu@chromium.org, jonross@chromium.org,
asvitkine@chromium.org
Link to the patchset: https://codereview.chromium.org/1188713007/#ps180001
(title: "Removed typedef in unittest.")

[commit-bot: I haz the power, 2015-06-26 17:39:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1188713007/180001

[commit-bot: I haz the power, 2015-06-26 19:37:58]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2015-06-26 19:39:00]

Patchset 10 (id:??) landed as
https://crrev.com/0d89d6ac4a77feaa44da9cb4abb456ca800981b4
Cr-Commit-Position: refs/heads/master@{#336442}

[bruthig, 2015-06-26 19:42:11]

oshima@, I had to rework the death test to get it to work on windows.  Can you
take a quick look at
 - ui/base/resource/material_design/material_design_controller_unittest.cc

[tdanderson, 2015-06-26 21:38:23]

https://codereview.chromium.org/1188713007/diff/180001/chrome/browser/about_f...
File chrome/browser/about_flags.cc (right):

https://codereview.chromium.org/1188713007/diff/180001/chrome/browser/about_f...
chrome/browser/about_flags.cc:810: kOsWin | kOsCrOS,
I just noticed you're missing Linux here. Mind adding that in a follow-up?

[bruthig, 2015-06-29 14:18:57]

https://codereview.chromium.org/1188713007/diff/180001/chrome/browser/about_f...
File chrome/browser/about_flags.cc (right):

https://codereview.chromium.org/1188713007/diff/180001/chrome/browser/about_f...
chrome/browser/about_flags.cc:810: kOsWin | kOsCrOS,
On 2015/06/26 21:38:23, tdanderson wrote:
> I just noticed you're missing Linux here. Mind adding that in a follow-up?

https://codereview.chromium.org/1219683003