GTK: Always relayout the tab strip when the tab strip bounds change.

GTK: Always relayout the tab strip when the tab strip bounds change.

TabStripGtk::OnSizeAllocate() could fail to call Layout() or schedule Layout()
to be called in the future (and was reusing the code to resize the internal
tabs when a single tab was closed). The views implementation of the tabstrip
didn't use that path and would always relayout the entire tabstrip on bounds
changes.

BUG=79094
TEST=Create a window with more than 20 tabs in it. Very slowly shrink the window, one pixel at a time. The min/max/close buttons shouldn't overlap with the new tab button.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=110451

[Elliot Glaysher, 2011-11-15 22:53:55]

I've tested this in both ltr and rtl modes. I will, as a separate cleanup patch,
revert the remnants of r59467 now that the return value is unused.

[Evan Stade, 2011-11-16 04:13:54]

http://codereview.chromium.org/8568026/diff/2001/chrome/browser/ui/gtk/tabs/t...
File chrome/browser/ui/gtk/tabs/tab_strip_gtk.cc (right):

http://codereview.chromium.org/8568026/diff/2001/chrome/browser/ui/gtk/tabs/t...
chrome/browser/ui/gtk/tabs/tab_strip_gtk.cc:2093:
layout_factory_.InvalidateWeakPtrs();
I don't get this, why not coalesce calls, i.e. if there is already one scheduled
don't cancel it or schedule a new one

[Elliot Glaysher, 2011-11-16 17:59:49]

ptal

[Evan Stade, 2011-11-17 00:55:20]

lgtm assuming this doesn't cause a large increase in cpu usage during resize

[commit-bot: I haz the power, 2011-11-17 01:03:44]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/erg@chromium.org/8568026/5001

[commit-bot: I haz the power, 2011-11-17 06:10:43]

Change committed as 110451