Support for multiple block fragments in getClientRects().

Support for multiple block fragments in getClientRects().

Objects crossing column boundaries, for instance, should create one rectangle
for each column they live in.

Two old tests had to be updated, because they depended on the old and incorrect
behavior (pick the bigger / center column and create one huge rectangle there).

Add fragmentainerInFlowThread() to FragmentainerIterator. Removed the
updateOutput() thing. Instead, have the getters compute what they need on the
fly. This makes more sense now, since none of the (2) FragmentainerIterator
users need to calculate everything. Also don't require a clip rectangle.

Some extra attention is required when processing objects with a zero-height
bounding box now. Previously, we didn't need to worry about those, since no
bounding box means no painting, hit-testing, etc. But now, with
getBoundingClientRect(), life is different.

BUG=362232
Committed: https://crrev.com/7ebce92e1afa74a3c995b206bcb6b2f8b42689f4
Cr-Commit-Position: refs/heads/master@{#421643}

[mstensho (USE GERRIT), 2016-09-23 08:53:12]

The CQ bit was checked by mstensho@opera.com to run a CQ dry run

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

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-23 09:18:45]

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

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

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[mstensho (USE GERRIT), 2016-09-28 19:04:50]

The CQ bit was checked by mstensho@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-28 19:05:22]

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

[mstensho (USE GERRIT), 2016-09-28 19:09:48]

Description was changed from

==========
Support for multiple block fragments in getBoundingClientRect().

Objects crossing column boundaries, for instance, should create one rectangle
for each column they live in.

Two old tests had to be updated, because they depended on the old and incorrect
behavior (pick the bigger / center column and create one huge rectangle there).

Add fragmentainerInFlowThread() to FragmentainerIterator. Removed the
updateOutput() thing. Instead, have the getters compute what they need on the
fly. This makes more sense now, since none of the (2) FragmentainerIterator
users need to calculate everything. Also don't require a clip rectangle.

BUG=362232
==========

to

==========
Support for multiple block fragments in getBoundingClientRect().

Objects crossing column boundaries, for instance, should create one rectangle
for each column they live in.

Two old tests had to be updated, because they depended on the old and incorrect
behavior (pick the bigger / center column and create one huge rectangle there).

Add fragmentainerInFlowThread() to FragmentainerIterator. Removed the
updateOutput() thing. Instead, have the getters compute what they need on the
fly. This makes more sense now, since none of the (2) FragmentainerIterator
users need to calculate everything. Also don't require a clip rectangle.

Some extra attention is required when processing objects with a zero-height
bounding box now. Previously, we didn't need to worry about those, since no
bounding box means no painting, hit-testing, etc. But now, with
getBoundingClientRect(), life is different.

BUG=362232
==========

[mstensho (USE GERRIT), 2016-09-28 19:58:55]

mstensho@opera.com changed reviewers:
+ eae@chromium.org

[mstensho (USE GERRIT), 2016-09-28 19:58:56]

https://codereview.chromium.org/2360913004/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.cpp
(right):

https://codereview.chromium.org/2360913004/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.cpp:444:
lastColumn = firstColumn;
There's something fishy about this whole PageBoundaryRule business. I don't like
to do what I'm doing here.

[commit-bot: I haz the power, 2016-09-28 20:36:01]

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

[commit-bot: I haz the power, 2016-09-28 20:36:01]

Dry run: This issue passed the CQ dry run.

[eae, 2016-09-28 20:55:17]

The change itself makes sense and is very nicely implemented.

The description doesn't match the implementation though, you probably meant to
say getClientRects instead of getBoundingClientRect right as
getBoundingClientRect always returns a single rect bounding all of the client
rects.

Please clarify.

https://codereview.chromium.org/2360913004/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.cpp
(right):

https://codereview.chromium.org/2360913004/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.cpp:444:
lastColumn = firstColumn;
On 2016/09/28 19:58:55, mstensho wrote:
> There's something fishy about this whole PageBoundaryRule business. I don't
like
> to do what I'm doing here.

Yeah, this smells bad. Would you mind filing a bug about it and adding a link
here?

[mstensho (USE GERRIT), 2016-09-28 21:05:56]

Description was changed from

==========
Support for multiple block fragments in getBoundingClientRect().

Objects crossing column boundaries, for instance, should create one rectangle
for each column they live in.

Two old tests had to be updated, because they depended on the old and incorrect
behavior (pick the bigger / center column and create one huge rectangle there).

Add fragmentainerInFlowThread() to FragmentainerIterator. Removed the
updateOutput() thing. Instead, have the getters compute what they need on the
fly. This makes more sense now, since none of the (2) FragmentainerIterator
users need to calculate everything. Also don't require a clip rectangle.

Some extra attention is required when processing objects with a zero-height
bounding box now. Previously, we didn't need to worry about those, since no
bounding box means no painting, hit-testing, etc. But now, with
getBoundingClientRect(), life is different.

BUG=362232
==========

to

==========
Support for multiple block fragments in getClientRects().

Objects crossing column boundaries, for instance, should create one rectangle
for each column they live in.

Two old tests had to be updated, because they depended on the old and incorrect
behavior (pick the bigger / center column and create one huge rectangle there).

Add fragmentainerInFlowThread() to FragmentainerIterator. Removed the
updateOutput() thing. Instead, have the getters compute what they need on the
fly. This makes more sense now, since none of the (2) FragmentainerIterator
users need to calculate everything. Also don't require a clip rectangle.

Some extra attention is required when processing objects with a zero-height
bounding box now. Previously, we didn't need to worry about those, since no
bounding box means no painting, hit-testing, etc. But now, with
getBoundingClientRect(), life is different.

BUG=362232
==========

[mstensho (USE GERRIT), 2016-09-28 21:20:23]

Thanks for spotting the typo! Yes, I meant getClientRects().

https://codereview.chromium.org/2360913004/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.cpp
(right):

https://codereview.chromium.org/2360913004/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.cpp:444:
lastColumn = firstColumn;
On 2016/09/28 20:55:17, eae wrote:
> On 2016/09/28 19:58:55, mstensho wrote:
> > There's something fishy about this whole PageBoundaryRule business. I don't
> like
> > to do what I'm doing here.
> 
> Yeah, this smells bad. Would you mind filing a bug about it and adding a link
> here?

Good idea! crbug.com/651213

[eae, 2016-09-28 21:21:14]

LGTM

[eae, 2016-09-28 21:21:25]

The CQ bit was checked by eae@chromium.org

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

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-28 21:28:28]

Description was changed from

==========
Support for multiple block fragments in getClientRects().

Objects crossing column boundaries, for instance, should create one rectangle
for each column they live in.

Two old tests had to be updated, because they depended on the old and incorrect
behavior (pick the bigger / center column and create one huge rectangle there).

Add fragmentainerInFlowThread() to FragmentainerIterator. Removed the
updateOutput() thing. Instead, have the getters compute what they need on the
fly. This makes more sense now, since none of the (2) FragmentainerIterator
users need to calculate everything. Also don't require a clip rectangle.

Some extra attention is required when processing objects with a zero-height
bounding box now. Previously, we didn't need to worry about those, since no
bounding box means no painting, hit-testing, etc. But now, with
getBoundingClientRect(), life is different.

BUG=362232
==========

to

==========
Support for multiple block fragments in getClientRects().

Objects crossing column boundaries, for instance, should create one rectangle
for each column they live in.

Two old tests had to be updated, because they depended on the old and incorrect
behavior (pick the bigger / center column and create one huge rectangle there).

Add fragmentainerInFlowThread() to FragmentainerIterator. Removed the
updateOutput() thing. Instead, have the getters compute what they need on the
fly. This makes more sense now, since none of the (2) FragmentainerIterator
users need to calculate everything. Also don't require a clip rectangle.

Some extra attention is required when processing objects with a zero-height
bounding box now. Previously, we didn't need to worry about those, since no
bounding box means no painting, hit-testing, etc. But now, with
getBoundingClientRect(), life is different.

BUG=362232
==========

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

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-09-28 21:30:27]

Description was changed from

==========
Support for multiple block fragments in getClientRects().

Objects crossing column boundaries, for instance, should create one rectangle
for each column they live in.

Two old tests had to be updated, because they depended on the old and incorrect
behavior (pick the bigger / center column and create one huge rectangle there).

Add fragmentainerInFlowThread() to FragmentainerIterator. Removed the
updateOutput() thing. Instead, have the getters compute what they need on the
fly. This makes more sense now, since none of the (2) FragmentainerIterator
users need to calculate everything. Also don't require a clip rectangle.

Some extra attention is required when processing objects with a zero-height
bounding box now. Previously, we didn't need to worry about those, since no
bounding box means no painting, hit-testing, etc. But now, with
getBoundingClientRect(), life is different.

BUG=362232
==========

to

==========
Support for multiple block fragments in getClientRects().

Objects crossing column boundaries, for instance, should create one rectangle
for each column they live in.

Two old tests had to be updated, because they depended on the old and incorrect
behavior (pick the bigger / center column and create one huge rectangle there).

Add fragmentainerInFlowThread() to FragmentainerIterator. Removed the
updateOutput() thing. Instead, have the getters compute what they need on the
fly. This makes more sense now, since none of the (2) FragmentainerIterator
users need to calculate everything. Also don't require a clip rectangle.

Some extra attention is required when processing objects with a zero-height
bounding box now. Previously, we didn't need to worry about those, since no
bounding box means no painting, hit-testing, etc. But now, with
getBoundingClientRect(), life is different.

BUG=362232

Committed: https://crrev.com/7ebce92e1afa74a3c995b206bcb6b2f8b42689f4
Cr-Commit-Position: refs/heads/master@{#421643}
==========

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

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