Have Chrome draw top window border when using custom titlebar.

chrome/browser/ui/views/frame/glass_browser_frame_view.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/ui/views/frame/glass_browser_frame_view.h"
 
 #include <dwmapi.h>
 #include <utility>
 
 #include "base/win/windows_version.h"
@@ skipping 480 matching lines @@
 
 Windows10CaptionButton* GlassBrowserFrameView::CreateCaptionButton(
     ViewID button_type) {
   Windows10CaptionButton* button =
       new Windows10CaptionButton(this, button_type);
   AddChildView(button);
   return button;
 }
 
 void GlassBrowserFrameView::PaintTitlebar(gfx::Canvas* canvas) const {
+  // This color is the same as Edge uses and closely matches the appearance of
+  // an inactive activation border.
+  SkColor inactive_border_color = 0xFFA1A1A1;

[Peter Kasting, 2016/10/01 05:00:14]

Can't hardcode this.  It works for Edge because they also hardcode their frame
color, but we don't, and at least for now, need to respect the user's
active/inactive colors, both of which are customizable (though it's trickier to
customize the inactive one...).

It's possible to look up the current frame color via another Chrome function (I
forget the function name, I told Bret recently in a different code review and
can find it if you can't), and then compute the opaque frame color manually from
this, ideally in a way that matches Windows as much as is feasible.

[Bret, 2016/10/01 19:53:08]

I actually think the inactive border color is fixed. The inactive /frame/ color
is not, but that's not relevant here.

Make this value constexpr.

[Peter Kasting, 2016/10/01 20:53:03]

I think you're right: my normal inactive border color is ARGB 0x80565656, which
doesn't seem like it reflects my active/inactive window colors in any way.

For Edge's top border I get 0xFFA2A2A2, not A1 as above.  This is basically the
same color you'd get from the "real" inactive border atop #EFEFEF.  Dunno if
that means anything.

I would recheck the A2 vs. A1 issue and document the non-opaque inactive border
color here.

   SkColor frame_color = 0xFFCCCCCC;
   gfx::Rect tabstrip_bounds = GetBoundsForTabStrip(browser_view()->tabstrip());
 
   gfx::ScopedCanvas scoped_canvas(canvas);
   float scale = canvas->UndoDeviceScaleFactor();
   // This is the pixel-accurate version of WindowTopY(). Scaling the DIP values
   // here compounds precision error, which exposes the native Windows caption
   // buttons we need to draw over. (see the comment in
   // BrowserDesktopWindowTreeHostWin::UpdateDWMFrame()).
   const int y = IsMaximized() ? FrameTopBorderThicknessPx(false) : 1;
   SkPaint paint;
+  paint.setColor(
+      ShouldPaintAsActive()
+          ? GetThemeProvider()->GetColor(ThemeProperties::COLOR_FRAME)

[Bret, 2016/10/01 19:53:08]

This is the wrong color for the border. A good test is to set your background to
a solid #FFFFFF image and then set "Automatically pick an accent color from my
background." It'll give you a white border and a blue frame.

You'll need to add code to theme_service_win to get the correct color. I believe
this is correct:

First get the values "ColorizationColor" and "ColorizationColorBalance" from the
same registry key we're getting "AccentColor" from already. Define alpha as
ColorizationColorBalance / 100. Then for each channel R, G, and B of
ColorizationColor calculate: round(channel * alpha + 217 * (1 - alpha))

Since the border color can be different than the frame color it's stored as a
separate value in ColorizationColor. Then it's blended with grey based on
ColorizationColorBalance (which was settable via the UI in Windows 8 but is now
otherwise inaccessible). 217 is just the gray channel value you get when
ColorizationColorBalance is 0.

[Peter Kasting, 2016/10/01 20:53:02]

In other words:

  color_utils::AlphaBlend(ColorizationColor, SkColorSetRGB(0xD9, 0xD9, 0xD9),
                          std::round(255 * ColorizationColorBalance / 100.f));

Bret, do you know what the alpha channel value on the ColorizationColor means? 
For me it's set to 0xc4, but I don't know how that affects anything.

[Bret, 2016/10/01 21:43:10]

Ah yes, I never actually tried to write it into Chromium, I just had the math in
my notes.

COLORREF doesn't encode alpha. The high bits are a channel order code, 0xC4
means RGB and 0 means BGR. So don't worry about it.

+          : inactive_border_color);
+  canvas->DrawRect(gfx::RectF(0, 0, width() * scale, y), paint);

[Peter Kasting, 2016/10/01 05:00:14]

If we want to do this, we need justification in the comments about why
(basically, the info you responded to Bret with).

What does "causes everything to break" mean regarding having a nonzero top
inset?  I'm less familiar with this stuff maybe than you guys are and it'd be
nice to understand if there's some way of getting a transparent top border, even
if it's complicated, that doesn't cost power.  (It seems instinctively like such
a way ought to exist, but with the DWM, you never know...)

[Bret, 2016/10/01 19:53:08]

It's definitely impossible. With the insight that using
DwmExtendFrameIntoClientArea costs power I fully believe that Edge is making the
exact same tradeoff of sacrificing the transparent top border.

If you set the top client inset to >0 then Windows gives you a full default
titlebar, and if you mess with the window styles to remove it then hundreds of
lines of HWNDMessageHandler have to be rewritten. I have some detailed notes
about it if you want to know more.

I second adding some comments about this though.

[Peter Kasting, 2016/10/01 20:53:03]

"Have to be rewritten" like, out of scope for this patch, but we should probably
go there eventually, or "have to be rewritten" like, let's never do this, it
makes our lives horrible and things have bugs?

[Bret, 2016/10/01 21:43:10]

The latter, definitely the latter.

   paint.setColor(frame_color);
   canvas->DrawRect(
       gfx::RectF(0, y, width() * scale, tabstrip_bounds.bottom() * scale - y),
       paint);
-
-  // The 1 pixel line at the top is drawn by Windows when we leave that section
-  // of the window blank because we have called DwmExtendFrameIntoClientArea()
-  // inside BrowserDesktopWindowTreeHostWin::UpdateDWMFrame().
 }
 
 void GlassBrowserFrameView::PaintToolbarBackground(gfx::Canvas* canvas) const {
   // TODO(estade): can this be shared with OpaqueBrowserFrameView?
   gfx::Rect toolbar_bounds(browser_view()->GetToolbarBounds());
   if (toolbar_bounds.IsEmpty())
     return;
   gfx::Point toolbar_origin(toolbar_bounds.origin());
   ConvertPointToTarget(browser_view(), this, &toolbar_origin);
   toolbar_bounds.set_origin(toolbar_origin);
@@ skipping 245 matching lines @@
   static bool initialized = false;
   if (!initialized) {
     for (int i = 0; i < kThrobberIconCount; ++i) {
       throbber_icons_[i] =
           ui::LoadThemeIconFromResourcesDataDLL(IDI_THROBBER_01 + i);
       DCHECK(throbber_icons_[i]);
     }
     initialized = true;
   }
 }