Draw the same portion of the frame background behind the tabstrip in maximized

Draw the same portion of the frame background behind the tabstrip in maximized
mode as in restored mode.

Themes which tried to align the tab and frame images couldn't do so in both
maximized and restored modes, since the alignment changed; so they had to pick
one.  This makes the alignment the same in both modes so that themes which
looked correct in restored mode will now look correct in maximized mode as well.

The other way to fix this -- make restored mode match maximized mode -- isn't
possible, as that would put the top of the frame background image in the middle
of the top section of the frame in restored windows, leaving nothing above it.
This also means that for themes which chose to look correct in maximized mode
and wrong in restored mode, they'll now look wrong all the time :(.

BUG=none
TEST=Apply the "Dots" theme from the webstore.  The alignment of the tab and new tab button images against the frame background should be the same in maximized mode as in restored mode.
R=sky@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/8788219e9968bb22f4b850e3c129419fddf3dd21

[Peter Kasting, 2015-11-05 21:15:26]

pkasting@chromium.org changed reviewers:
+ sky@chromium.org

[Peter Kasting, 2015-11-05 21:15:27]

https://codereview.chromium.org/1412833008/diff/1/chrome/browser/ui/views/fra...
File chrome/browser/ui/views/frame/opaque_browser_frame_view.cc (left):

https://codereview.chromium.org/1412833008/diff/1/chrome/browser/ui/views/fra...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:635:
frame_background_->set_maximized_top_inset(kGTKThemeCondensedFrameTopInset);
Note that this is no longer necessary since the new code shifts up by 16 px, and
thus already does what this does and more.

[sky, 2015-11-06 16:49:48]

Ugh, this feels so wrong. But I don't have any better suggestions.
LGTM

https://codereview.chromium.org/1412833008/diff/1/chrome/browser/ui/views/fra...
File chrome/browser/ui/views/frame/browser_view_layout.cc (right):

https://codereview.chromium.org/1412833008/diff/1/chrome/browser/ui/views/fra...
chrome/browser/ui/views/frame/browser_view_layout.cc:327: int y =
browser_view_->y() + delegate_->GetTopInsetInBrowserView(true);
This looks so wrong. 321 supplies false, and this supplies true. How about some
comments?

[Peter Kasting, 2015-11-06 22:04:04]

https://codereview.chromium.org/1412833008/diff/1/chrome/browser/ui/views/fra...
File chrome/browser/ui/views/frame/browser_view_layout.cc (right):

https://codereview.chromium.org/1412833008/diff/1/chrome/browser/ui/views/fra...
chrome/browser/ui/views/frame/browser_view_layout.cc:327: int y =
browser_view_->y() + delegate_->GetTopInsetInBrowserView(true);
On 2015/11/06 16:49:48, sky wrote:
> This looks so wrong. 321 supplies false, and this supplies true. How about
some
> comments?

Sure, will add.

In brief, the summary is:
* "false" gives you the true, current height above the tabstrip.  We want to use
that in the first instance since we're positioning the window elements.
* "true" gives you the height above a restored-mode tabstrip.  We want to draw
the frame background with this so that it's always aligned as if the window is
restored.

[commit-bot: I haz the power, 2015-11-07 03:53:25]

Patchset 2 (id:??) landed as
https://crrev.com/8788219e9968bb22f4b850e3c129419fddf3dd21
Cr-Commit-Position: refs/heads/master@{#358512}

[Peter Kasting, 2015-11-07 03:53:53]

Committed patchset #2 (id:20001) manually as
8788219e9968bb22f4b850e3c129419fddf3dd21 (presubmit successful).