1520301 - Content shifts to the left after scrolling with webrender

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Adam Stevenson [:adamopenweb]]

Attachment: screenshot with webrender enabled

Steps to reproduce:

1. Launch Nightly with Webrender enabled
2. Navigate to: https://www.canadacomputers.com/product_info.php?cPath=4_1210_64&item_id=111559
3. Click on "Check Other Stores >"
4. Scroll down

Expected behaviour:
Content scrolls normally

Actual behaviour:
The content all shifts to the left and out of view, if webrender is enabled

Tested in Nightly 66.0a1 (2019-01-15) (64-bit) for MacOS 10.13 and Windows 10.

Comment 1

[Sotaro Ikeda [:sotaro]]

Checked regression range.

---

9:02.99 INFO: No more inbound revisions, bisection finished.
9:02.99 INFO: Last good revision: 5420c29d49d60862617a6b0014548eb1c7c814f3
9:02.99 INFO: First bad revision: bd59070a24d72da867cf1531e89e75ffed2848ae
9:03.00 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5420c29d49d60862617a6b0014548eb1c7c814f3&tochange=bd59070a24d72da867cf1531e89e75ffed2848ae

Comment 2

[Dzmitry Malyshau [:kvark]]

Thanks for finding the regression range!
I hope this is fixed by https://hg.mozilla.org/integration/autoland/rev/078e5984f999

Comment 3

[Dzmitry Malyshau [:kvark]]

Nope. Apparently, that's a different bug.

Comment 4

[Dzmitry Malyshau [:kvark]]

Roughly speaking, the logic change that causes this problem is the following. The old code used to push the clip ID of the reference frame being pushed with push_reference_frame, so that it implicitly affects all the children. The new code doesn't have the clip/scroll stack on WR DL API side, and Gecko has a bit of save/restore logic in places like StackingContextHelper. Apparently, there is a case where Gecko doesn't use the pushed reference frame the same way old code did.

Comment 5

[Dzmitry Malyshau [:kvark]]

Attachment: Fix scroll frame default positioning

When scroll frames are created, and no explicit parent is provided,
the old code used to take the ClipID from the c/s stack. The stack
has been removed on WR side, and this parent assignment got lost.

This change takes the SpatialID from the top of the stack on Gecko
side to replicate the old behavior.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d4b7dbc0379f
Fix scroll frame default positioning r=jrmuizel

Comment 9

[Cosmin Sabou [:CosminS]]

Backed out changeset for reftest failures on gfx/tests/reftest/1519754.html.

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=rg1&tochange=ef66755764d4c6cba370621b13b8a32a54eddeb4&fromchange=cfbd8823f3c5b9cfea52d1a519f0b0d2a4aa2345&group_state=expanded&selectedJob=222320464

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=222320464&repo=autoland&lineNumber=11188
Reftest analyzer: https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/CQgGJzJKRfmpKUl-ZlGZvw/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

Backout link: https://hg.mozilla.org/integration/autoland/rev/e3cb5a5ef667973b60314b67e13184f5d9cedb18

Comment 10

[Emilio Cobos Álvarez [:emilio]]

You should be able to use the Ahem font, or otherwise any other content as the content of the scroll frame.

Comment 11

[Dzmitry Malyshau [:kvark]]

Re-landing now with the fixed reftest.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c3d4685b58a5
Fix scroll frame default positioning r=jrmuizel

Comment 13

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/c3d4685b58a5

Comment 14

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I reproduced this issue using Fx 66.0a1(build ID: 20190115221511, on Windows 10 x64.
I can confirm this issue is fixed, I verified using Fx 66.0-build2, on Windows 10 x64, macOS 10.13.6 and Ubuntu 16.06 LTS