Fix scrollIntoViewIfNeeded when scroll box has no height or width.

Fix scrollIntoViewIfNeeded when scroll box has no height or width.

When calling scrollIntoView with a centering behavior (e.g.
scrollIntoViewIfNeeded and focus-initiated scrollIntoView) on a scroll
box with no height or width the current behavior is to not scroll the
box and call scrollIntoView with the same rect to the next ancestor box.
This is clearly wrong since we won't scroll the rect into view of the
child box so the ancestor box will try to scrollIntoView a rect that
might be outside its visible rect, even though the child box is within
it. This is the surprising behavior seen in the bug; focus() is called
on an element inside a scroller with zero height and large scrollTop
which causes the main frame to scroll up instead of the scroller.

The fix in this CL is to give a box with a zero width or height a
minimum size. This means we'll scroll the content "into view" as if the
box were just very small in that dimension. This matches the behavior in
Firefox. It also prevents surprising scrolls in ancestor boxes.

BUG=585368
Committed: https://crrev.com/2e27d335ad7b6aa54d71f3f1259649909b4c4387
Cr-Commit-Position: refs/heads/master@{#385579}

[bokan, 2016-04-05 23:07:41]

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

[commit-bot: I haz the power, 2016-04-05 23:08:07]

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

[commit-bot: I haz the power, 2016-04-06 00:07:51]

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

[commit-bot: I haz the power, 2016-04-06 00:07:51]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[bokan, 2016-04-06 11:20:31]

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

[commit-bot: I haz the power, 2016-04-06 11:20:47]

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

[bokan, 2016-04-06 11:33:02]

Description was changed from

==========
Fix scrollIntoViewIfNeeded when scroll box has no height or width.

BUG=585368
==========

to

==========
Fix scrollIntoViewIfNeeded when scroll box has no height or width.

When calling scrollIntoView with a centering behavior (e.g.
scrollIntoViewIfNeeded and focus-initiated scrollIntoView) on a scroll
box with no height or width the current behavior is to not scroll the
box and call scrollIntoView with the same rect to the next ancestor box.
This is clearly wrong since we won't scroll the rect into view of the
child box so the ancestor box will try to scrollIntoView a rect that
might be outside its visible rect, even though the child box is within
it. This is the surprising behavior seen in the bug; focus() is called
on an element inside a scroller with zero height and large scrollTop
which causes the main frame to scroll up instead of the scroller.

The fix in this CL is to give a box with a zero width or height a
minimum size. This means we'll scroll the content "into view" as if the
box were just very small in that dimension. This matches the behavior in
Firefox. It also prevents surprising scrolls in ancestor boxes.

BUG=585368
==========

[bokan, 2016-04-06 11:33:02]

bokan@chromium.org changed reviewers:
+ ajuma@chromium.org

[bokan, 2016-04-06 11:33:20]

Hi Ali, I see you've touched ScrollAlignment a bunch. PTAL.

[commit-bot: I haz the power, 2016-04-06 12:33:24]

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

[commit-bot: I haz the power, 2016-04-06 12:33:25]

Dry run: This issue passed the CQ dry run.

[ajuma, 2016-04-06 13:25:20]

lgtm

[bokan, 2016-04-06 13:26:04]

+leviw@ for TODO removal in LayoutUnit

[bokan, 2016-04-06 13:26:33]

bokan@chromium.org changed reviewers:
+ leviw@chromium.org

[bokan, 2016-04-06 13:26:33]

+leviw@ for LayoutUnit (for real this time)

[leviw_travelin_and_unemployed, 2016-04-06 23:19:55]

Hehe, thanks for the catch! LGTM for removing my TODO :)

[leviw_travelin_and_unemployed, 2016-04-06 23:19:58]

The CQ bit was checked by leviw@chromium.org

[commit-bot: I haz the power, 2016-04-06 23:20:55]

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

[commit-bot: I haz the power, 2016-04-06 23:45:31]

Description was changed from

==========
Fix scrollIntoViewIfNeeded when scroll box has no height or width.

When calling scrollIntoView with a centering behavior (e.g.
scrollIntoViewIfNeeded and focus-initiated scrollIntoView) on a scroll
box with no height or width the current behavior is to not scroll the
box and call scrollIntoView with the same rect to the next ancestor box.
This is clearly wrong since we won't scroll the rect into view of the
child box so the ancestor box will try to scrollIntoView a rect that
might be outside its visible rect, even though the child box is within
it. This is the surprising behavior seen in the bug; focus() is called
on an element inside a scroller with zero height and large scrollTop
which causes the main frame to scroll up instead of the scroller.

The fix in this CL is to give a box with a zero width or height a
minimum size. This means we'll scroll the content "into view" as if the
box were just very small in that dimension. This matches the behavior in
Firefox. It also prevents surprising scrolls in ancestor boxes.

BUG=585368
==========

to

==========
Fix scrollIntoViewIfNeeded when scroll box has no height or width.

When calling scrollIntoView with a centering behavior (e.g.
scrollIntoViewIfNeeded and focus-initiated scrollIntoView) on a scroll
box with no height or width the current behavior is to not scroll the
box and call scrollIntoView with the same rect to the next ancestor box.
This is clearly wrong since we won't scroll the rect into view of the
child box so the ancestor box will try to scrollIntoView a rect that
might be outside its visible rect, even though the child box is within
it. This is the surprising behavior seen in the bug; focus() is called
on an element inside a scroller with zero height and large scrollTop
which causes the main frame to scroll up instead of the scroller.

The fix in this CL is to give a box with a zero width or height a
minimum size. This means we'll scroll the content "into view" as if the
box were just very small in that dimension. This matches the behavior in
Firefox. It also prevents surprising scrolls in ancestor boxes.

BUG=585368
==========

[commit-bot: I haz the power, 2016-04-06 23:45:34]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-04-06 23:47:39]

Description was changed from

==========
Fix scrollIntoViewIfNeeded when scroll box has no height or width.

When calling scrollIntoView with a centering behavior (e.g.
scrollIntoViewIfNeeded and focus-initiated scrollIntoView) on a scroll
box with no height or width the current behavior is to not scroll the
box and call scrollIntoView with the same rect to the next ancestor box.
This is clearly wrong since we won't scroll the rect into view of the
child box so the ancestor box will try to scrollIntoView a rect that
might be outside its visible rect, even though the child box is within
it. This is the surprising behavior seen in the bug; focus() is called
on an element inside a scroller with zero height and large scrollTop
which causes the main frame to scroll up instead of the scroller.

The fix in this CL is to give a box with a zero width or height a
minimum size. This means we'll scroll the content "into view" as if the
box were just very small in that dimension. This matches the behavior in
Firefox. It also prevents surprising scrolls in ancestor boxes.

BUG=585368
==========

to

==========
Fix scrollIntoViewIfNeeded when scroll box has no height or width.

When calling scrollIntoView with a centering behavior (e.g.
scrollIntoViewIfNeeded and focus-initiated scrollIntoView) on a scroll
box with no height or width the current behavior is to not scroll the
box and call scrollIntoView with the same rect to the next ancestor box.
This is clearly wrong since we won't scroll the rect into view of the
child box so the ancestor box will try to scrollIntoView a rect that
might be outside its visible rect, even though the child box is within
it. This is the surprising behavior seen in the bug; focus() is called
on an element inside a scroller with zero height and large scrollTop
which causes the main frame to scroll up instead of the scroller.

The fix in this CL is to give a box with a zero width or height a
minimum size. This means we'll scroll the content "into view" as if the
box were just very small in that dimension. This matches the behavior in
Firefox. It also prevents surprising scrolls in ancestor boxes.

BUG=585368

Committed: https://crrev.com/2e27d335ad7b6aa54d71f3f1259649909b4c4387
Cr-Commit-Position: refs/heads/master@{#385579}
==========

[commit-bot: I haz the power, 2016-04-06 23:47:40]

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