Content shifts to the left after scrolling with webrender

VERIFIED FIXED in Firefox 66

Status

()

defect
P3
normal
VERIFIED FIXED
4 months ago
2 months ago

People

(Reporter: adamopenweb, Assigned: kvark)

Tracking

(Blocks 1 bug, {regression})

66 Branch
mozilla66
Desktop
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox64 unaffected, firefox65 unaffected, firefox66 verified)

Details

()

Attachments

(2 attachments)

Reporter

Description

4 months ago

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.

Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: regression
OS: Unspecified → All
Priority: -- → P3

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

Assignee

Comment 2

4 months ago

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

Assignee: nobody → dmalyshau
Status: NEW → ASSIGNED
Assignee

Comment 3

4 months ago

Nope. Apparently, that's a different bug.

Assignee

Comment 4

4 months ago

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.

Assignee

Comment 5

4 months ago
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.
Duplicate of this bug: 1520454
Duplicate of this bug: 1519754

Comment 8

4 months ago
Pushed by dmalyshau@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d4b7dbc0379f
Fix scroll frame default positioning r=jrmuizel

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

Assignee

Comment 11

4 months ago

Re-landing now with the fixed reftest.

Flags: needinfo?(dmalyshau)

Comment 12

4 months ago
Pushed by dmalyshau@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c3d4685b58a5
Fix scroll frame default positioning r=jrmuizel

Comment 13

4 months ago
bugherder
Status: ASSIGNED → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

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

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.