Don't fall back to default incognito colors and tints when using a

chrome/browser/themes/theme_service.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/themes/theme_service.h"
 
 #include <stddef.h>
 
 #include <algorithm>
 
@@ skipping 477 matching lines @@
           SK_ColorWHITE, GetColor(kLabelBackground, incognito));
     case ThemeProperties::COLOR_SUPERVISED_USER_LABEL_BACKGROUND:
       return color_utils::BlendTowardOppositeLuma(
           GetColor(ThemeProperties::COLOR_FRAME, incognito), 0x80);
     case ThemeProperties::COLOR_SUPERVISED_USER_LABEL_BORDER:
       return color_utils::AlphaBlend(GetColor(kLabelBackground, incognito),
                                      SK_ColorBLACK, 230);
 #endif
   }
 
-  return ThemeProperties::GetDefaultColor(id, incognito);
+  // Always fall back to the non-incognito color when there's a custom theme.
+  return ThemeProperties::GetDefaultColor(id, incognito && !theme_supplier_);

[Peter Kasting, 2016/03/18 20:53:50]

Hmm.  Couldn't this also break some themes, if we have color IDs that differ
between normal and incognito pre-MD?  In such cases, the old behavior would have
been that we fall back to a default incognito color for these IDs, but now we're
falling back to a non-incognito color.

[Evan Stade, 2016/03/18 21:15:21]

Perhaps, but I checked about 8 themes and the only breakages I saw were due to
bad theme values (e.g. they made the toolbar color dark but didn't change the
button tint). DEFAULT_TINT_BUTTONS in pre-MD is the same for incognito and not
incognito, and this is probably true of a lot of colors.

Do you think it would be safer/preferable to make this

bool use_incognito = incognito && (!theme_supplier_ || !IsModeMaterial());

[Peter Kasting, 2016/03/18 21:22:53]

No; instead I think we should only disable |use_incognito| for cases where we've
added an incognito-specific default that didn't use to have an
incognito-specific default.  That will make us behave exactly the way we used
to.  Themes might rely on the other behaviors, and restricting to MD would just
mean the themes would only break in MD, rahter than preventing them from
breaking at all.

 }
 
 color_utils::HSL ThemeService::GetTint(int id, bool incognito) const {
   DCHECK(CalledOnValidThread());
 
   color_utils::HSL hsl;
   if (theme_supplier_ && theme_supplier_->GetTint(id, &hsl))
     return hsl;
 
-  return ThemeProperties::GetDefaultTint(id, incognito);
+  // Always fall back to the non-incognito tint when there's a custom theme.
+  return ThemeProperties::GetDefaultTint(id, incognito && !theme_supplier_);
 }
 
 void ThemeService::ClearAllThemeData() {
   if (!ready_)
     return;
 
   SwapThemeSupplier(nullptr);
 
   // Clear our image cache.
   FreePlatformCaches();
@@ skipping 332 matching lines @@
 
 #if defined(ENABLE_SUPERVISED_USERS)
 bool ThemeService::IsSupervisedUser() const {
   return profile_->IsSupervised();
 }
 
 void ThemeService::SetSupervisedUserTheme() {
   SetCustomDefaultTheme(new SupervisedUserTheme);
 }
 #endif