Have Chrome draw top window border when using custom titlebar.

chrome/browser/themes/theme_service_win.cc

Index: chrome/browser/themes/theme_service_win.cc
diff --git a/chrome/browser/themes/theme_service_win.cc b/chrome/browser/themes/theme_service_win.cc
index 4aab2c4219d3244790e283ae8a1a8e88eccb7f66..afb0cc98feb3700aaa47698ac8ec472d71e122b2 100644
--- a/chrome/browser/themes/theme_service_win.cc
+++ b/chrome/browser/themes/theme_service_win.cc
@@ -10,6 +10,7 @@
 #include "chrome/grit/theme_resources.h"
 #include "skia/ext/skia_utils_win.h"
 #include "ui/base/win/shell.h"
+#include "ui/gfx/color_utils.h"
 
 ThemeServiceWin::ThemeServiceWin() {
   // This just checks for Windows 10 instead of calling ShouldUseDwmFrameColor()
@@ -39,6 +40,9 @@ SkColor ThemeServiceWin::GetDefaultColor(int id, bool incognito) const {
     if (id == ThemeProperties::COLOR_FRAME)
       return dwm_frame_color_;
 
+    if (id == ThemeProperties::COLOR_ACCENT_BORDER)
+      return dwm_accent_border_color_;
+
     // Inactive native windows on Windows 10 always have a white frame.
     if (id == ThemeProperties::COLOR_FRAME_INACTIVE)
         return SK_ColorWHITE;
@@ -63,6 +67,33 @@ void ThemeServiceWin::OnDwmKeyUpdated() {
           ? skia::COLORREFToSkColor(accent_color)
           : SK_ColorWHITE;
 
+  dwm_accent_border_color_ = SK_ColorWHITE;
+  DWORD colorization_color, colorization_color_balance;
+  if ((dwm_key_->ReadValueDW(L"ColorizationColor", &colorization_color) ==

[Peter Kasting, 2016/10/11 21:09:34]

Does calling DwmGetColorizationColor() get this value?

You could probably get both these values with DwmGetColorizationParameters()
(see http://www.codeproject.com/Articles/610909/Changing-Windows-Aero-Color on
how to use this undocumented API), but that may be more trouble than it's worth.

+       ERROR_SUCCESS) &&
+      (dwm_key_->ReadValueDW(L"ColorizationColorBalance",
+                             &colorization_color_balance) == ERROR_SUCCESS)) {
+    // The accent border color is a linear blend between the colorization
+    // color and the neutral #d9d9d9. colorization_color_balance is the
+    // percentage of the colorization color in that blend.
+    //
+    // On Windows version 1611 colorization_color_balance can be 0xfffffff3 if
+    // the accent color is taken from the background and either the background
+    // is a solid color or was just changed to a slideshow. It's unclear what
+    // that value's supposed to mean, so change it to 80 to match Edge's
+    // behavior.
+    if (colorization_color_balance > 100)
+      colorization_color_balance = 80;
+
+    // colorization_color's high byte can be 0xc4 or 0, so replace it with
+    // an 0xff alpha to make an opaque color.

[Peter Kasting, 2016/10/11 20:01:38]

Nit: I would be clearer about the meaning of this byte, e.g.:

|colorization_color|'s high byte is not an alpha value but a channel order code,
so replace it with 0xff to make this an opaque ARGB color.

(Bret, we don't need to check for 0x00 and byteswap BGR -> RGB, do we?)

[Bret, 2016/10/11 20:48:19]

Oh oops! You're right, this could be wrong if the color is in BGR order.
ColorizationColor is always in RGB format in practice unless someone mucks with
the registry, but it's more correct to use the helper that accent_color uses
above, skia::COLORREFToSkColor, which uses Windows macros. Then this whole
comment can go away.

[Peter Kasting, 2016/10/11 20:56:51]

Hmm, that function looks like it assumes 0BGR instead of looking at the high
byte.

Maybe we need to use that function and add a high byte check?  I see about 4
callsites of this currently, so hopefully auditing these to be sure that was the
right thing to do wouldn't be onerous.

[Bret, 2016/10/11 21:10:15]

Oh I misread the definition of COLORREFToSkColor. The first branch in the
preprocessor switch looks correct to me, it's using the Get[RGB]Value macros,
which are provided by Windows and should always do the right thing. So maybe
we're actually getting the second branch? It's not a huge deal in either case,
it'd just be nice to be correct if someone manually edits the registry to be
0BGR order lol.

[Peter Kasting, 2016/10/11 21:26:26]

As noted in my reply to jbauman, I think this is always 0x??RRGGBB, and the top
byte is not a channel order indicator.  It's not a COLORREF stuffed into a reg
key.  So I think the existing code here is good.

+    SkColor input_color = SkColorSetA(colorization_color, 0xff);
+
+    dwm_accent_border_color_ =
+        color_utils::AlphaBlend(input_color, SkColorSetRGB(0xd9, 0xd9, 0xd9),
+                                255 * colorization_color_balance / 100.f);

[Peter Kasting, 2016/10/11 20:01:38]

This implicitly truncates float to int.  Do one of these (they should be
equivalent):

gfx::ToRoundedInt(255 * colorization_color_balance / 100.f)
Tween::LinearIntValueBetween(colorization_color_balance / 100., 0, 255);

+  }
+
   // Watch for future changes.
   if (!dwm_key_->StartWatching(base::Bind(
           &ThemeServiceWin::OnDwmKeyUpdated, base::Unretained(this))))