Remove some pre-MD code from toolbar/tabstrip/frame.

Remove some pre-MD code from toolbar/tabstrip/frame.

Initially I only intended to remove pre-MD code from OpaqueBrowserFrameView, but this led to removals in other files as well. I did not attempt to remove all pre-MD code from all of these files, so, for example, tab.cc still has some pre-MD code.

BUG=648281
TBR=oshima@chromium.org

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

[Evan Stade, 2016-09-21 21:08:43]

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

[commit-bot: I haz the power, 2016-09-21 21:09:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Evan Stade, 2016-09-21 21:20:09]

Description was changed from

==========
Remove some pre-MD code from toolbar/tabstrip/frame.

BUG=648281
==========

to

==========
Remove some pre-MD code from toolbar/tabstrip/frame.

Initially I only intended to remove pre-MD code from OpaqueBrowserFrameView, but
this lead to removals in other files as well. I did not attempt to remove all
pre-MD code from all of these files, so, for example, tab.cc still has some
pre-MD code.

BUG=648281
==========

[Evan Stade, 2016-09-21 21:20:09]

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

[Evan Stade, 2016-09-21 21:21:29]

Description was changed from

==========
Remove some pre-MD code from toolbar/tabstrip/frame.

Initially I only intended to remove pre-MD code from OpaqueBrowserFrameView, but
this lead to removals in other files as well. I did not attempt to remove all
pre-MD code from all of these files, so, for example, tab.cc still has some
pre-MD code.

BUG=648281
==========

to

==========
Remove some pre-MD code from toolbar/tabstrip/frame.

Initially I only intended to remove pre-MD code from OpaqueBrowserFrameView, but
this led to removals in other files as well. I did not attempt to remove all
pre-MD code from all of these files, so, for example, tab.cc still has some
pre-MD code.

BUG=648281
==========

[Evan Stade, 2016-09-21 21:23:08]

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

[commit-bot: I haz the power, 2016-09-21 21:23:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-21 22:15:28]

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

[commit-bot: I haz the power, 2016-09-21 22:15:29]

Dry run: This issue passed the CQ dry run.

[Peter Kasting, 2016-09-22 23:27:25]

LGTM

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/themes/b...
File chrome/browser/themes/browser_theme_pack.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/themes/b...
chrome/browser/themes/browser_theme_pack.cc:162: #endif
So we still use the back/forward/reload/stop bitmaps etc. somehow on non-Mac,
but not home?

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.mm (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.mm:146: const
int top_inset = -border->height();
Nit: Just use "- border->height()" directly below

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/frame/browser_view_layout.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/browser_view_layout.cc:405: int y = top;
Nit: Just use |top| directly below

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/frame/glass_browser_frame_view.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:108: // button look
glitchy.
This comment should go away, as all the code it was talking about is now gone.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:418: // TODO(estade):
can this be shared with OpaqueBrowserFrameView?
Ideally, we'd share a lot more.  My goal during most of the MD refactors was to
move the glass and opaque frame implementations closer and closer together in
hopes of someday fully or partly combining the two.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:434:
tp->GetColor(ThemeProperties::COLOR_TOOLBAR_BOTTOM_SEPARATOR);
Nit: Now that we have a lot less code, some of these are only used once and can
probably be inlined, viz. |separator_color|, |h|, |bg_y|, |bg|.

For the others, try to move them as close to first use as possible.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:445: // Top stroke. 
The toolbar has no side strokes.
Nit: No real need for the second sentence anymore as no toolbar ever has a side
stroke in MD now.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:462: // The client
edge images start at the top of the toolbar.
Nit: Comment probably not needed anymore.

I would probably just move all the rest of these under the "// Draw the client
edge images" comment below.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:465: const gfx::Rect
toolbar_bounds(browser_view()->GetToolbarBounds());
Nit: Inline into next statement

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:472: const SkColor
toolbar_color = tp->GetColor(ThemeProperties::COLOR_TOOLBAR);
Nit: Inline below.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/frame/opaque_browser_frame_view.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:554: void
OpaqueBrowserFrameView::PaintToolbarBackground(gfx::Canvas* canvas) const {
Nit: Assume my relevant comments from the glass frame also apply in this
function/file

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:611: const bool
toolbar_visible = IsToolbarVisible();
Nit: Inline below

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:612: int img_y_offset
= 0;
Nit: This variable is now dead (always 0).

That means |img_y| below can also be eliminated and we can just use |y|
everywhere.  (I would then rename |img_h| to |h| too.)

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:628: // Shadow.
Nit: Remove this comment and blank line above; the next statement is part of the
comment above.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:633: // In maximized
mode, the only edge to draw is the top one, so we're done.
Nit: Now that the code above does much less, it would be nice to restructure
this function more like this, to avoid unnecessary calculations:

{
  // If the toolbar isn't going to draw a top edge for us, draw one ourselves.
  const bool tabstrip_visible = browser_view()->IsTabStripVisible();
  gfx::Rect client_bounds =
      layout_->CalculateClientAreaBounds(width(), height());
  const int x = client_bounds.x();
  int y = client_bounds.y();
  const int w = client_bounds.width();
  if (!tabstrip_visible) {
    const gfx::Rect top_edge(x - kClientEdgeThickness, y - 1,
                             w + (2 * kClientEdgeThickness), 1);
    BrowserView::Paint1pxHorizontalLine(canvas, GetToolbarTopSeparatorColor(),
                                        top_edge, true);
  }

  // In maximized mode, the only edge to draw is the top one, so we're done.
  if (layout_->IsTitleBarCondensed())
    return;

  ... everything else

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:642: // Draw the
client edge images.
Nit: edge images -> edges, since the rects (which aren't images) are included in
this block too.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/tabs/tab.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab.cc:381: SkScalar top = SkIntToScalar(0);
Saga of code review:

I was gonna tell you to just use 0 below directly, then realized this whole
block is dead anyway.

Then I was gonna tell you to just go ahead and rip the block out now, and then
figured you'd have decided to do that if you wanted to, so you're aiming for
"just make it compile, let's not get CL creep".

Then I was thinking "well why bother to remove the conditional below then?" but
I realized it probably triggered a dead code warning.  That made me wonder if
drying to "fix" this block was really easier than just ripping it out.

I don't care.  Do what you want :)

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab.cc:887: return GetLayoutInsets(TAB).top();
Nit: ?

  // TODO(estade): Just nuke this function and call GetLayoutInsets() directly
from callers

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/toolbar/toolbar_view.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/toolbar/toolbar_view.cc:110: return (parent_height -
child_height) / 2;
Nit: I'd just do this inline in the two callers, now that it's simple and clear
(arguably, clearer than the function call).  Here's the first caller:

  const int child_height =
      std::min(back_->GetPreferredSize().height(), height());
  const int child_y = (height() - child_height) / 2;

Or use Rect::ClampToCenteredSize() instead:

  gfx::Rect child_rect = GetLocalBounds();
  child_rect.ClampToCenteredSize(back_->GetPreferredSize());
  // Use child_rect.y()/.height() below, or declare temps

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/toolbar/toolbar_view.cc:642: // count as intersection
with this view).
Nit: Does this parenthetical have meaning anymore?  I take removing
content_shadow_height() to mean the "top shadow edge" is gone.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/toolbar/toolbar_view.cc:643: if (rect.bottom() < 0)
Hmm, I suspect this was a slight bug?  Maybe they meant "<=" instead of "<".

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/toolbar/toolbar_view.cc:646: return
ViewTargeterDelegate::DoesIntersectRect(this, rect);
Nit: Simpler:

  // Fall through to the tab strip above us if none of |rect| intersects;
  // otherwise let our superclass take care of it.
  return (rect.bottom > 0) &&
         ViewTargeterDelegate::DoesIntersectRect(this, rect);

Note that this assumes that using "<" above was, indeed, a bug.

Though maybe with no "top shadow edge" we don't even need to override this
method at all.  Seems like the base ViewTargeterDelegate should now just do the
right thing?

[Evan Stade, 2016-09-23 00:31:06]

estade@chromium.org changed reviewers:
+ oshima@chromium.org

[Evan Stade, 2016-09-23 00:31:08]

Thanks for extremely detailed review.

+oshima TBR for resources

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/themes/b...
File chrome/browser/themes/browser_theme_pack.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/themes/b...
chrome/browser/themes/browser_theme_pack.cc:162: #endif
On 2016/09/22 23:27:24, Peter Kasting wrote:
> So we still use the back/forward/reload/stop bitmaps etc. somehow on non-Mac,
> but not home?

yea unfortunately there are still a couple places in secondary ui that use
these.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.mm (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.mm:146: const
int top_inset = -border->height();
On 2016/09/22 23:27:24, Peter Kasting wrote:
> Nit: Just use "- border->height()" directly below

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/frame/browser_view_layout.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/browser_view_layout.cc:405: int y = top;
On 2016/09/22 23:27:24, Peter Kasting wrote:
> Nit: Just use |top| directly below

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/frame/glass_browser_frame_view.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:108: // button look
glitchy.
On 2016/09/22 23:27:25, Peter Kasting wrote:
> This comment should go away, as all the code it was talking about is now gone.

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:418: // TODO(estade):
can this be shared with OpaqueBrowserFrameView?
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Ideally, we'd share a lot more.  My goal during most of the MD refactors was
to
> move the glass and opaque frame implementations closer and closer together in
> hopes of someday fully or partly combining the two.

well, they're getting pretty close, so good job!

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:434:
tp->GetColor(ThemeProperties::COLOR_TOOLBAR_BOTTOM_SEPARATOR);
On 2016/09/22 23:27:24, Peter Kasting wrote:
> Nit: Now that we have a lot less code, some of these are only used once and
can
> probably be inlined, viz. |separator_color|, |h|, |bg_y|, |bg|.
> 
> For the others, try to move them as close to first use as possible.

Done. I didn't move tp, x, y, or w because the only way to move them closer is
to put them below the // Background comment, which doesn't seem more readable to
me.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:445: // Top stroke. 
The toolbar has no side strokes.
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: No real need for the second sentence anymore as no toolbar ever has a
side
> stroke in MD now.

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:462: // The client
edge images start at the top of the toolbar.
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: Comment probably not needed anymore.
> 
> I would probably just move all the rest of these under the "// Draw the client
> edge images" comment below.

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:465: const gfx::Rect
toolbar_bounds(browser_view()->GetToolbarBounds());
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: Inline into next statement

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/glass_browser_frame_view.cc:472: const SkColor
toolbar_color = tp->GetColor(ThemeProperties::COLOR_TOOLBAR);
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: Inline below.

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/frame/opaque_browser_frame_view.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:554: void
OpaqueBrowserFrameView::PaintToolbarBackground(gfx::Canvas* canvas) const {
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: Assume my relevant comments from the glass frame also apply in this
> function/file

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:611: const bool
toolbar_visible = IsToolbarVisible();
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: Inline below

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:612: int img_y_offset
= 0;
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: This variable is now dead (always 0).
> 
> That means |img_y| below can also be eliminated and we can just use |y|
> everywhere.  (I would then rename |img_h| to |h| too.)

Done. img_h is equivalent to height, so I'll just use that.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:628: // Shadow.
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: Remove this comment and blank line above; the next statement is part of
the
> comment above.

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:633: // In maximized
mode, the only edge to draw is the top one, so we're done.
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: Now that the code above does much less, it would be nice to restructure
> this function more like this, to avoid unnecessary calculations:
> 
> {
>   // If the toolbar isn't going to draw a top edge for us, draw one ourselves.
>   const bool tabstrip_visible = browser_view()->IsTabStripVisible();
>   gfx::Rect client_bounds =
>       layout_->CalculateClientAreaBounds(width(), height());
>   const int x = client_bounds.x();
>   int y = client_bounds.y();
>   const int w = client_bounds.width();
>   if (!tabstrip_visible) {
>     const gfx::Rect top_edge(x - kClientEdgeThickness, y - 1,
>                              w + (2 * kClientEdgeThickness), 1);
>     BrowserView::Paint1pxHorizontalLine(canvas, GetToolbarTopSeparatorColor(),
>                                         top_edge, true);
>   }
> 
>   // In maximized mode, the only edge to draw is the top one, so we're done.
>   if (layout_->IsTitleBarCondensed())
>     return;
> 
>   ... everything else

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:642: // Draw the
client edge images.
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: edge images -> edges, since the rects (which aren't images) are included
in
> this block too.

Done.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/tabs/tab.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab.cc:381: SkScalar top = SkIntToScalar(0);
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Saga of code review:
> 
> I was gonna tell you to just use 0 below directly, then realized this whole
> block is dead anyway.
> 
> Then I was gonna tell you to just go ahead and rip the block out now, and then
> figured you'd have decided to do that if you wanted to, so you're aiming for
> "just make it compile, let's not get CL creep".
> 
> Then I was thinking "well why bother to remove the conditional below then?"
but
> I realized it probably triggered a dead code warning.  That made me wonder if
> drying to "fix" this block was really easier than just ripping it out.
> 
> I don't care.  Do what you want :)

yes to cl creep. I think I removed the block below on my own initiative rather
than after being nagged by the compiler, but you're right, it's all dead anyway
so it doesn't make much sense.

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab.cc:887: return GetLayoutInsets(TAB).top();
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: ?
> 
>   // TODO(estade): Just nuke this function and call GetLayoutInsets() directly
> from callers

todone

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/toolbar/toolbar_view.cc (right):

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/toolbar/toolbar_view.cc:643: if (rect.bottom() < 0)
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Hmm, I suspect this was a slight bug?  Maybe they meant "<=" instead of "<".

in fact I think we can ditch this entire function

https://codereview.chromium.org/2360803002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/toolbar/toolbar_view.cc:646: return
ViewTargeterDelegate::DoesIntersectRect(this, rect);
On 2016/09/22 23:27:25, Peter Kasting wrote:
> Nit: Simpler:
> 
>   // Fall through to the tab strip above us if none of |rect| intersects;
>   // otherwise let our superclass take care of it.
>   return (rect.bottom > 0) &&
>          ViewTargeterDelegate::DoesIntersectRect(this, rect);
> 
> Note that this assumes that using "<" above was, indeed, a bug.
> 
> Though maybe with no "top shadow edge" we don't even need to override this
> method at all.  Seems like the base ViewTargeterDelegate should now just do
the
> right thing?

yea, I just came to the same conclusion

[Evan Stade, 2016-09-23 00:31:26]

Description was changed from

==========
Remove some pre-MD code from toolbar/tabstrip/frame.

Initially I only intended to remove pre-MD code from OpaqueBrowserFrameView, but
this led to removals in other files as well. I did not attempt to remove all
pre-MD code from all of these files, so, for example, tab.cc still has some
pre-MD code.

BUG=648281
==========

to

==========
Remove some pre-MD code from toolbar/tabstrip/frame.

Initially I only intended to remove pre-MD code from OpaqueBrowserFrameView, but
this led to removals in other files as well. I did not attempt to remove all
pre-MD code from all of these files, so, for example, tab.cc still has some
pre-MD code.

BUG=648281
TBR=oshima@chromium.org
==========

[Evan Stade, 2016-09-23 00:31:48]

The CQ bit was checked by estade@chromium.org

[Evan Stade, 2016-09-23 00:31:48]

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

[commit-bot: I haz the power, 2016-09-23 00:32:36]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-23 01:18:59]

Description was changed from

==========
Remove some pre-MD code from toolbar/tabstrip/frame.

Initially I only intended to remove pre-MD code from OpaqueBrowserFrameView, but
this led to removals in other files as well. I did not attempt to remove all
pre-MD code from all of these files, so, for example, tab.cc still has some
pre-MD code.

BUG=648281
TBR=oshima@chromium.org
==========

to

==========
Remove some pre-MD code from toolbar/tabstrip/frame.

Initially I only intended to remove pre-MD code from OpaqueBrowserFrameView, but
this led to removals in other files as well. I did not attempt to remove all
pre-MD code from all of these files, so, for example, tab.cc still has some
pre-MD code.

BUG=648281
TBR=oshima@chromium.org
==========

[commit-bot: I haz the power, 2016-09-23 01:19:00]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-09-23 01:22:24]

Description was changed from

==========
Remove some pre-MD code from toolbar/tabstrip/frame.

Initially I only intended to remove pre-MD code from OpaqueBrowserFrameView, but
this led to removals in other files as well. I did not attempt to remove all
pre-MD code from all of these files, so, for example, tab.cc still has some
pre-MD code.

BUG=648281
TBR=oshima@chromium.org
==========

to

==========
Remove some pre-MD code from toolbar/tabstrip/frame.

Initially I only intended to remove pre-MD code from OpaqueBrowserFrameView, but
this led to removals in other files as well. I did not attempt to remove all
pre-MD code from all of these files, so, for example, tab.cc still has some
pre-MD code.

BUG=648281
TBR=oshima@chromium.org

Committed: https://crrev.com/af2ccbcc10d941a54c45676bb141ebf1e6f74d25
Cr-Commit-Position: refs/heads/master@{#420532}
==========

[commit-bot: I haz the power, 2016-09-23 01:22:26]

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