Update layer position on scroll origin change

Update layer position on scroll origin change

Layers on the compositor are positioned relative to the physical origin
in the top left corner, regardless of writing direction. In Blink, the
scroll offset is relative to the scroll origin which changes based on
writing direction. This means that changing the scroll origin, without
changing the scroll offset, still requires updating the scroll layer's
position on the compositor.

Previously, this happened by accident as a change in scroll origin would
often cause scrollbar existence to change and this would implicitly
position the compositor layers through calling
PaintLayerCompositor::FrameViewDidChangeSize. This call is unneeded when
using overlay scrollbars since no sizes changed so I removed it in
https://crrev.com/f5a4f9d38de7403d172ad20f78c462048eae37bc. This caused
us to miss positioning scroll layers in cases where we wouldn't otherwise.

This patch adds a step after a compositing update that checks if the
scroll origin changed and explicitly updates the scroll layer position.

BUG=707542
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2812523003
Cr-Commit-Position: refs/heads/master@{#463904}
Committed: https://chromium.googlesource.com/chromium/src/+/9c51c9ab54994c6baa9eedde1eb86b549dd8e314

[bokan, 2017-04-10 18:54:13]

Description was changed from

==========
Update layer position on scroll origin change

BUG=707542
==========

to

==========
Update layer position on scroll origin change

BUG=707542
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[bokan, 2017-04-10 18:54:51]

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

[commit-bot: I haz the power, 2017-04-10 18:55:48]

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, 2017-04-10 20:23:06]

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

[commit-bot: I haz the power, 2017-04-10 20:23:07]

Dry run: This issue passed the CQ dry run.

[bokan, 2017-04-11 18:31:46]

Description was changed from

==========
Update layer position on scroll origin change

BUG=707542
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
Update layer position on scroll origin change

Layers on the compositor are positioned relative to the physical origin
in the top left corner, regardless of writing direction. In Blink, the
scroll offset is relative to the scroll origin which changes based on
writing direction. This means that changing the scroll origin, without
changing the scroll offset, still requires updating the scroll layer's
position on the compositor.

Previously, this happened by accident as a change in scroll origin would
often cause scrollbar existence to change and this would implicitly
position the compositor layers through calling
PaintLayerCompositor::FrameViewDidChangeSize. This call is unneeded when
using overlay scrollbars since no sizes changed so I removed it in
https://crrev.com/f5a4f9d38de7403d172ad20f78c462048eae37bc. This caused
us to miss positioning scroll layers in cases where we wouldn't otherwise.

This patch adds a step after a compositing update that checks if the
scroll origin changed and explicitly updates the scroll layer position.

BUG=707542
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[bokan, 2017-04-11 18:34:45]

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

[skobes, 2017-04-11 22:54:11]

lgtm

[bokan, 2017-04-11 22:55:12]

The CQ bit was checked by bokan@chromium.org

[commit-bot: I haz the power, 2017-04-11 22:56:07]

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, 2017-04-12 00:58:28]

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

[commit-bot: I haz the power, 2017-04-12 00:58:29]

Try jobs failed on following builders:
  linux_layout_tests_slimming_paint_v2 on master.tryserver.chromium.linux
(JOB_TIMED_OUT, build hasn't started yet, builder probably lacks capacity)

[pdr., 2017-04-12 02:03:33]

On 2017/04/12 at 00:58:29, commit-bot wrote:
> Try jobs failed on following builders:
>   linux_layout_tests_slimming_paint_v2 on master.tryserver.chromium.linux
(JOB_TIMED_OUT, build hasn't started yet, builder probably lacks capacity)

This is due to under-capacity on the spv2 trybot. Should be fixed tomorrow.
Re-cq'in for ya'

[pdr., 2017-04-12 02:03:35]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2017-04-12 02:04:24]

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, 2017-04-12 02:28:03]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1491962615745720,
"parent_rev": "94e9d9cf0302323949e90805222c8aa342b53641", "commit_rev":
"9c51c9ab54994c6baa9eedde1eb86b549dd8e314"}

[commit-bot: I haz the power, 2017-04-12 02:28:51]

Description was changed from

==========
Update layer position on scroll origin change

Layers on the compositor are positioned relative to the physical origin
in the top left corner, regardless of writing direction. In Blink, the
scroll offset is relative to the scroll origin which changes based on
writing direction. This means that changing the scroll origin, without
changing the scroll offset, still requires updating the scroll layer's
position on the compositor.

Previously, this happened by accident as a change in scroll origin would
often cause scrollbar existence to change and this would implicitly
position the compositor layers through calling
PaintLayerCompositor::FrameViewDidChangeSize. This call is unneeded when
using overlay scrollbars since no sizes changed so I removed it in
https://crrev.com/f5a4f9d38de7403d172ad20f78c462048eae37bc. This caused
us to miss positioning scroll layers in cases where we wouldn't otherwise.

This patch adds a step after a compositing update that checks if the
scroll origin changed and explicitly updates the scroll layer position.

BUG=707542
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
Update layer position on scroll origin change

Layers on the compositor are positioned relative to the physical origin
in the top left corner, regardless of writing direction. In Blink, the
scroll offset is relative to the scroll origin which changes based on
writing direction. This means that changing the scroll origin, without
changing the scroll offset, still requires updating the scroll layer's
position on the compositor.

Previously, this happened by accident as a change in scroll origin would
often cause scrollbar existence to change and this would implicitly
position the compositor layers through calling
PaintLayerCompositor::FrameViewDidChangeSize. This call is unneeded when
using overlay scrollbars since no sizes changed so I removed it in
https://crrev.com/f5a4f9d38de7403d172ad20f78c462048eae37bc. This caused
us to miss positioning scroll layers in cases where we wouldn't otherwise.

This patch adds a step after a compositing update that checks if the
scroll origin changed and explicitly updates the scroll layer position.

BUG=707542
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2812523003
Cr-Commit-Position: refs/heads/master@{#463904}
Committed:
https://chromium.googlesource.com/chromium/src/+/9c51c9ab54994c6baa9eedde1eb8...
==========

[commit-bot: I haz the power, 2017-04-12 02:28:53]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/9c51c9ab54994c6baa9eedde1eb8...

[bokan, 2017-04-12 10:37:25]

On 2017/04/12 02:28:53, commit-bot: I haz the power wrote:
> Committed patchset #2 (id:20001) as
>
https://chromium.googlesource.com/chromium/src/+/9c51c9ab54994c6baa9eedde1eb8...

Thanks PDR!