Compute snap offsets according to CSS Scroll Snap Spec Level 1

Compute snap offsets according to CSS Scroll Snap Spec Level 1

Add logic to compute snap offsets (those defined on snap container and snap
areas) according to the published spec [1].

SnapCoordinator maintains the mapping between snap containers and the snap
areas. This mapping is stored in |LayoutBoxRareData| and updated on style
change, attach, and detach events via hooks in |LayoutBox::styleWillChange| ,
|LayoutBox::insertedIntoTree| and |LayoutBox::willBeDestoryed|.

This implementation is the naive approach as described in [2]. It does not
attempt to track which snap areas have moved in relation to their container to
minimize  snap offsets re-computation. It simply re-computes all snap points
every time they are needed.

At the moment the computed snap offsets are not used for anything except to pass
the tests. In future,  |SnapCoordinator| will compute them as part of the
document lifecycle and send necessary updates to the Compositor Worker instance
which is going to be responsible for snapping during scrolls.

[1] https://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
[2] https://docs.google.com/document/d/1BO0EgcMe3DTsO1uwM_psZeJ_Gz5OZR-oYrpJBKAJLoU/edit?pli=1

This is a re-land of https://crrev.com/1188563005

BUG=
TBR=eae@chromium.org

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

[majidvp, 2016-05-10 21:21:06]

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

[commit-bot: I haz the power, 2016-05-10 21:21:38]

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

[majidvp, 2016-05-10 21:21:41]

Description was changed from

==========
Compute snap offsets according to CSS Scroll Snap Spec Level 1

Add logic to compute snap offsets (those defined on snap container and snap
areas) according to the published spec [1].

SnapCoordinator maintains the mapping between snap containers and the snap
areas. This mapping is stored in |LayoutBoxRareData| and updated on style
change, attach, and detach events via hooks in |LayoutBox::styleWillChange| ,
|LayoutBox::insertedIntoTree| and |LayoutBox::willBeDestoryed|.

This implementation is the naive approach as described in [2]. It does not
attempt to track which snap areas have moved in relation to their container to
minimize  snap offsets re-computation. It simply re-computes all snap points
every time they are needed.

At the moment the computed snap offsets are not used for anything except to pass
the tests. In future,  |SnapCoordinator| will compute them as part of the
document lifecycle and send necessary updates to the Compositor Worker instance
which is going to be responsible for snapping during scrolls.

[1] https://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
[2]
https://docs.google.com/document/d/1BO0EgcMe3DTsO1uwM_psZeJ_Gz5OZR-oYrpJBKAJL...


This is a re-land of https://crrev.com/1188563005

BUG=
==========

to

==========
Compute snap offsets according to CSS Scroll Snap Spec Level 1

Add logic to compute snap offsets (those defined on snap container and snap
areas) according to the published spec [1].

SnapCoordinator maintains the mapping between snap containers and the snap
areas. This mapping is stored in |LayoutBoxRareData| and updated on style
change, attach, and detach events via hooks in |LayoutBox::styleWillChange| ,
|LayoutBox::insertedIntoTree| and |LayoutBox::willBeDestoryed|.

This implementation is the naive approach as described in [2]. It does not
attempt to track which snap areas have moved in relation to their container to
minimize  snap offsets re-computation. It simply re-computes all snap points
every time they are needed.

At the moment the computed snap offsets are not used for anything except to pass
the tests. In future,  |SnapCoordinator| will compute them as part of the
document lifecycle and send necessary updates to the Compositor Worker instance
which is going to be responsible for snapping during scrolls.

[1] https://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
[2]
https://docs.google.com/document/d/1BO0EgcMe3DTsO1uwM_psZeJ_Gz5OZR-oYrpJBKAJL...


This is a re-land of https://crrev.com/1188563005

BUG=
TBR=eae
==========

[commit-bot: I haz the power, 2016-05-10 21:24:37]

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

[commit-bot: I haz the power, 2016-05-10 21:24:38]

Dry run: Try jobs failed on following builders:
  ios-device on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-gn on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-gn/bui...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[majidvp, 2016-05-10 21:25:28]

majidvp@chromium.org changed reviewers:
+ skobes@chromium.org

[majidvp, 2016-05-10 21:25:29]

skobes@: This is a reland of crrev.com/1188563005/. The original CL
was reverted due to issues on Android bot. I believe the issue was because in
the tests I was assuming a scrollbar width (15px) which is incorrect on Android
with overlay scrollbars. I have confirmed that the test is passing locally now.

Patch set 1: original CL
Patch set 2: Fixes the test to make is cross platform

Please review the fix.

[majidvp, 2016-05-10 21:41:59]

Patchset #3 (id:40001) has been deleted

[skobes, 2016-05-10 21:53:45]

lgtm w/ nit

https://codereview.chromium.org/1970563002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/page/scrolling/SnapCoordinatorTest.cpp
(right):

https://codereview.chromium.org/1970563002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/scrolling/SnapCoordinatorTest.cpp:134:
size_t expectedHorizontalSnapOffsets = snapContainer().scrollWidth() -
snapContainer().clientWidth();
size_t is meant for byte sizes of objects and memory allocations... I'd just use
int here.

[majidvp, 2016-05-11 16:24:46]

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

[commit-bot: I haz the power, 2016-05-11 16:25:03]

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

[commit-bot: I haz the power, 2016-05-11 17:45:32]

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

[commit-bot: I haz the power, 2016-05-11 17:45:33]

Dry run: This issue passed the CQ dry run.

[majidvp, 2016-05-11 18:08:00]

Description was changed from

==========
Compute snap offsets according to CSS Scroll Snap Spec Level 1

Add logic to compute snap offsets (those defined on snap container and snap
areas) according to the published spec [1].

SnapCoordinator maintains the mapping between snap containers and the snap
areas. This mapping is stored in |LayoutBoxRareData| and updated on style
change, attach, and detach events via hooks in |LayoutBox::styleWillChange| ,
|LayoutBox::insertedIntoTree| and |LayoutBox::willBeDestoryed|.

This implementation is the naive approach as described in [2]. It does not
attempt to track which snap areas have moved in relation to their container to
minimize  snap offsets re-computation. It simply re-computes all snap points
every time they are needed.

At the moment the computed snap offsets are not used for anything except to pass
the tests. In future,  |SnapCoordinator| will compute them as part of the
document lifecycle and send necessary updates to the Compositor Worker instance
which is going to be responsible for snapping during scrolls.

[1] https://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
[2]
https://docs.google.com/document/d/1BO0EgcMe3DTsO1uwM_psZeJ_Gz5OZR-oYrpJBKAJL...


This is a re-land of https://crrev.com/1188563005

BUG=
TBR=eae
==========

to

==========
Compute snap offsets according to CSS Scroll Snap Spec Level 1

Add logic to compute snap offsets (those defined on snap container and snap
areas) according to the published spec [1].

SnapCoordinator maintains the mapping between snap containers and the snap
areas. This mapping is stored in |LayoutBoxRareData| and updated on style
change, attach, and detach events via hooks in |LayoutBox::styleWillChange| ,
|LayoutBox::insertedIntoTree| and |LayoutBox::willBeDestoryed|.

This implementation is the naive approach as described in [2]. It does not
attempt to track which snap areas have moved in relation to their container to
minimize  snap offsets re-computation. It simply re-computes all snap points
every time they are needed.

At the moment the computed snap offsets are not used for anything except to pass
the tests. In future,  |SnapCoordinator| will compute them as part of the
document lifecycle and send necessary updates to the Compositor Worker instance
which is going to be responsible for snapping during scrolls.

[1] https://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
[2]
https://docs.google.com/document/d/1BO0EgcMe3DTsO1uwM_psZeJ_Gz5OZR-oYrpJBKAJL...


This is a re-land of https://crrev.com/1188563005

BUG=
TBR=eae@chromium.org
==========

[majidvp, 2016-05-11 18:08:40]

The CQ bit was checked by majidvp@chromium.org

[majidvp, 2016-05-11 18:08:41]

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

[commit-bot: I haz the power, 2016-05-11 18:09:44]

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

[commit-bot: I haz the power, 2016-05-11 18:15:28]

Description was changed from

==========
Compute snap offsets according to CSS Scroll Snap Spec Level 1

Add logic to compute snap offsets (those defined on snap container and snap
areas) according to the published spec [1].

SnapCoordinator maintains the mapping between snap containers and the snap
areas. This mapping is stored in |LayoutBoxRareData| and updated on style
change, attach, and detach events via hooks in |LayoutBox::styleWillChange| ,
|LayoutBox::insertedIntoTree| and |LayoutBox::willBeDestoryed|.

This implementation is the naive approach as described in [2]. It does not
attempt to track which snap areas have moved in relation to their container to
minimize  snap offsets re-computation. It simply re-computes all snap points
every time they are needed.

At the moment the computed snap offsets are not used for anything except to pass
the tests. In future,  |SnapCoordinator| will compute them as part of the
document lifecycle and send necessary updates to the Compositor Worker instance
which is going to be responsible for snapping during scrolls.

[1] https://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
[2]
https://docs.google.com/document/d/1BO0EgcMe3DTsO1uwM_psZeJ_Gz5OZR-oYrpJBKAJL...


This is a re-land of https://crrev.com/1188563005

BUG=
TBR=eae@chromium.org
==========

to

==========
Compute snap offsets according to CSS Scroll Snap Spec Level 1

Add logic to compute snap offsets (those defined on snap container and snap
areas) according to the published spec [1].

SnapCoordinator maintains the mapping between snap containers and the snap
areas. This mapping is stored in |LayoutBoxRareData| and updated on style
change, attach, and detach events via hooks in |LayoutBox::styleWillChange| ,
|LayoutBox::insertedIntoTree| and |LayoutBox::willBeDestoryed|.

This implementation is the naive approach as described in [2]. It does not
attempt to track which snap areas have moved in relation to their container to
minimize  snap offsets re-computation. It simply re-computes all snap points
every time they are needed.

At the moment the computed snap offsets are not used for anything except to pass
the tests. In future,  |SnapCoordinator| will compute them as part of the
document lifecycle and send necessary updates to the Compositor Worker instance
which is going to be responsible for snapping during scrolls.

[1] https://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
[2]
https://docs.google.com/document/d/1BO0EgcMe3DTsO1uwM_psZeJ_Gz5OZR-oYrpJBKAJL...


This is a re-land of https://crrev.com/1188563005

BUG=
TBR=eae@chromium.org
==========

[commit-bot: I haz the power, 2016-05-11 18:15:31]

Committed patchset #4 (id:80001)

[commit-bot: I haz the power, 2016-05-11 18:16:41]

Description was changed from

==========
Compute snap offsets according to CSS Scroll Snap Spec Level 1

Add logic to compute snap offsets (those defined on snap container and snap
areas) according to the published spec [1].

SnapCoordinator maintains the mapping between snap containers and the snap
areas. This mapping is stored in |LayoutBoxRareData| and updated on style
change, attach, and detach events via hooks in |LayoutBox::styleWillChange| ,
|LayoutBox::insertedIntoTree| and |LayoutBox::willBeDestoryed|.

This implementation is the naive approach as described in [2]. It does not
attempt to track which snap areas have moved in relation to their container to
minimize  snap offsets re-computation. It simply re-computes all snap points
every time they are needed.

At the moment the computed snap offsets are not used for anything except to pass
the tests. In future,  |SnapCoordinator| will compute them as part of the
document lifecycle and send necessary updates to the Compositor Worker instance
which is going to be responsible for snapping during scrolls.

[1] https://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
[2]
https://docs.google.com/document/d/1BO0EgcMe3DTsO1uwM_psZeJ_Gz5OZR-oYrpJBKAJL...


This is a re-land of https://crrev.com/1188563005

BUG=
TBR=eae@chromium.org
==========

to

==========
Compute snap offsets according to CSS Scroll Snap Spec Level 1

Add logic to compute snap offsets (those defined on snap container and snap
areas) according to the published spec [1].

SnapCoordinator maintains the mapping between snap containers and the snap
areas. This mapping is stored in |LayoutBoxRareData| and updated on style
change, attach, and detach events via hooks in |LayoutBox::styleWillChange| ,
|LayoutBox::insertedIntoTree| and |LayoutBox::willBeDestoryed|.

This implementation is the naive approach as described in [2]. It does not
attempt to track which snap areas have moved in relation to their container to
minimize  snap offsets re-computation. It simply re-computes all snap points
every time they are needed.

At the moment the computed snap offsets are not used for anything except to pass
the tests. In future,  |SnapCoordinator| will compute them as part of the
document lifecycle and send necessary updates to the Compositor Worker instance
which is going to be responsible for snapping during scrolls.

[1] https://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
[2]
https://docs.google.com/document/d/1BO0EgcMe3DTsO1uwM_psZeJ_Gz5OZR-oYrpJBKAJL...

This is a re-land of https://crrev.com/1188563005

BUG=
TBR=eae@chromium.org

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

[commit-bot: I haz the power, 2016-05-11 18:16:43]

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