[FastTextAutosizer] Do not inflate table parts that do not need layout

[FastTextAutosizer] Do not inflate table parts that do not need layout

FastTextAutosizer::inflateTable pre-inflates table cells so that
the table layout algorithm has an upper bound for table cell sizes.
After inflateTable pre-inflates cells, the layout pass will come
around and correctly size cells through beginLayout(). This patch
fixes a bug where cells were pre-inflated without later being laid out.

The bug that affected codereview.chromium.org and amazon.com both
involved nested tables with images. When images load, they can
force a layout up their parent chain because their size can change.
During layout, we would then call inflateTable and pre-inflate the
entire table but only the image's cell would actually get laid out.

BUG=357299
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=171406

[skobes, 2014-04-13 03:19:26]

lgtm

Is this separate from the line height issue?

[pdr., 2014-04-13 03:24:43]

On 2014/04/13 03:19:26, skobes wrote:
> lgtm
> 
> Is this separate from the line height issue?

Thanks for the quick review.

This is one of the main line height issues. There may be more hiding in there,
but this gets most of the ones I know about.

[pdr., 2014-04-13 03:24:47]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2014-04-13 03:24:52]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/pdr@chromium.org/236033005/20001

[commit-bot: I haz the power, 2014-04-13 03:53:59]

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

[commit-bot: I haz the power, 2014-04-13 03:54:00]

Try jobs failed on following builders:
  tryserver.blink on win_blink_rel

[pdr, 2014-04-13 03:55:09]

The CQ bit was checked by pdr@google.com

[commit-bot: I haz the power, 2014-04-13 03:55:15]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/pdr@chromium.org/236033005/20001

[commit-bot: I haz the power, 2014-04-13 04:28:18]

Change committed as 171406

[skobes, 2014-04-13 16:55:55]

On 2014/04/13 03:24:43, pdr wrote:
> This is one of the main line height issues. There may be more hiding in there,
> but this gets most of the ones I know about.

How does pre-inflation of a table cell break the line height?  It's not clear
from the change description what the connection is.

[pdr., 2014-04-13 18:34:20]

On 2014/04/13 16:55:55, skobes wrote:
> On 2014/04/13 03:24:43, pdr wrote:
> > This is one of the main line height issues. There may be more hiding in
there,
> > but this gets most of the ones I know about.
> 
> How does pre-inflation of a table cell break the line height?  It's not clear
> from the change description what the connection is.

There are at least two issues with inflating text without going through layout:
1) The repaint logic is hooked into layout so applying the multiplier without
layout won't invalidate the text for paint. The end effect is that when you
select the text, scroll the page, or just invalidate the text somehow, it
repaints much differently. Because we still over-paint (especially tables), this
effect was masked on many pages.
2) A block's height is determined by its contents and inflating text children
without later laying out the block will lead to overlapping text (multiplied
text drawn using un-multiplied heights).

I think a combination of these are what we saw as the "line height bug".