Draw popup window toolbars as only containing a location bar.

Draw popup window toolbars as only containing a location bar.

The glass frame basically did this, but the opaque frame drew a small "toolbar
surround" around the location bar.  There was no real benefit to this and it
wasn't clear how to handle it for material mode, so I just moved to the simpler
presentation everywhere.

In the process, this changes the responsibility for drawing the popup-mode
location bar border from the location bar to the frame.  This allows for a
fairly significant simplification of the location bar and related code, e.g.
nuking the popup-related functionality entirely from BackgroundWith1PxBorder.

BUG=none
TEST=On Windows XP, open a popup window.  The location bar side edges should simply be a single pixel-wide strip contiguous with the edges of the content area.

Committed: https://crrev.com/b8075a8e803b4892a91bff87260cdc03da3a1f22
Cr-Commit-Position: refs/heads/master@{#360708}

[Peter Kasting, 2015-11-19 00:50:39]

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

[Peter Kasting, 2015-11-19 00:50:39]

As I mentioned in the previous CL I sent you, I still need to do more testing to
determine precisely how far the glass frame needs to go on Win 7.  I can do that
either before or after landing this; if I land this first and some parts aren't
needed it will be easy to just remove those bits.

[Peter Kasting, 2015-11-19 08:48:14]

Patch set 2 contains a few fixes:

* Remove a redundant chunk of code in
OpaqueBrowserFrameView::PaintMaximizedFrameBorder() that is trying to do the
same thing as some of the code in PaintClientEdge() (paint the divider at the
bottom of the titlebar).

* Use client_bounds.y() in the PaintClientEdge() functions in place of
frame()->client_view()->y(); AFAICT they should always be set to the same thing,
but if we're already getting |client_bounds| and using it for the other
coordinates, why not be specific.

* I finally found out how to test the animating location bar.  Fix
LocationBarView::Animation*() to re-layout the NonClientView instead of just
saying the toolbar size has changed.  Because of my changes in
https://codereview.chromium.org/1460483003/ , the positioning of elements in the
window can shift around when the animation toggles between a zero-height and
nonzero-height location bar, we need to ensure that e.g. the BrowserView gets
repositioned as the animation progresses.

This last fix really should have been part of
https://codereview.chromium.org/1460483003/ , but I didn't know what to test
until now, so rolling it in here.

[Peter Kasting, 2015-11-19 09:37:15]

The CQ bit was checked by pkasting@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-11-19 09:38:21]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1455193003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1455193003/20001

[commit-bot: I haz the power, 2015-11-19 09:40:40]

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

[commit-bot: I haz the power, 2015-11-19 09:40:41]

Dry run: Try jobs failed on following builders:
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[sky, 2015-11-19 17:35:12]

LGTM

[Peter Kasting, 2015-11-19 23:04:48]

FYI:

* I just tested this on Ash.  AFAICT this doesn't introduce any new problems,
and in fact makes popup/app windows look a little less glitchy.

* After testing on Win 7, I simplified the glass code to not add the APP_TOP
images, since it indeed doesn't need them.

* Since I think "tabstrip visible" always implies "toolbar visible", I
simplified the logic in PaintClientEdge() slightly in both opaque and glass
frames.

These changes are relatively minor, so I'm going to go ahead and land without
re-review; feel free to speak up if you see something you want me to correct as
a followup.

[Peter Kasting, 2015-11-19 23:04:55]

The CQ bit was checked by pkasting@chromium.org

[Peter Kasting, 2015-11-19 23:04:56]

The patchset sent to the CQ was uploaded after l-g-t-m from sky@chromium.org
Link to the patchset: https://codereview.chromium.org/1455193003/#ps40001
(title: "Glass cleanups")

[commit-bot: I haz the power, 2015-11-19 23:08:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1455193003/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1455193003/40001

[commit-bot: I haz the power, 2015-11-20 01:14:48]

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

[commit-bot: I haz the power, 2015-11-20 01:14:49]

Try jobs failed on following builders:
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_TIMED_OUT, no build
URL)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_TIMED_OUT, no build URL)

[Peter Kasting, 2015-11-20 01:22:29]

The CQ bit was checked by pkasting@chromium.org

[commit-bot: I haz the power, 2015-11-20 01:23:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1455193003/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1455193003/40001

[commit-bot: I haz the power, 2015-11-20 01:39:18]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-11-20 01:40:09]

Patchset 3 (id:??) landed as
https://crrev.com/b8075a8e803b4892a91bff87260cdc03da3a1f22
Cr-Commit-Position: refs/heads/master@{#360708}