1576514 - Assertion failure: false (Two layers that scroll together have different ancestor transforms), at gfx/layers/apz/src/APZCTreeManager.cpp:1173

Status: NEW

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

Description

[Hiroyuki Ikezoe (:hiro)]

Attachment: parent.html

Similar to bug 1491000 and bug 1450686, but this assertion happens only with enabling fission that means a test case that causes the assertion has an out-of-process iframe. I am going to attach the parent html here and will attach the child html file in a later comment.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Attachment: child.html

To reproduce the assertion you need to specify fission related preferences something like this;

./mach run --setpref "fission.autostart=true" --setpref "fission.oopif.attribute=true" --setpref="gfx.webrender.all=true" parent.html

Comment 2

[Hiroyuki Ikezoe (:hiro)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

To reproduce the assertion you need to specify fission related preferences something like this;

./mach run --setpref "fission.autostart=true" --setpref "fission.oopif.attribute=true" --setpref="gfx.webrender.all=true" parent.html

Forgot to say that you also need to scroll by mouse wheel or some such.

Comment 3

[Botond Ballo [:botond] [standards meeting Nov 4-9]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

./mach run --setpref "fission.autostart=true" --setpref "fission.oopif.attribute=true" --setpref="gfx.webrender.all=true" parent.html

Are you including the WebRender pref here because it's required for Fission to work? Or just required for this bug to reproduce?

Comment 4

[Hiroyuki Ikezoe (:hiro)]

It's for reproducing this assertion.

Comment 5

[Botond Ballo [:botond] [standards meeting Nov 4-9]]

Attachment: APZC tree dump

Since we don't have a layers dump with WebRender, I hacked the APZC tree dump to print the scroll nodes' transforms (attached).

The scroll nodes on line 5 and line 11 of the dump share the same APZC (APZC (0x100000002, 2, 2)), but have different transforms ([ 1 0; 0 1; 14 767; ] vs. [ I ]), thus triggering the assertion.

Unfortunately I have no quick ideas on why this might be happening. It will take some digging through the WebRenderCommandBuilder code that produces the WebRenderScrollData and related objects to understand how we end up in this situation.

Comment 6

[Timothy Nikkel (:tnikkel)]

(In reply to Botond Ballo [:botond] from comment #5)

Since we don't have a layers dump with WebRender, I hacked the APZC tree dump to print the scroll nodes' transforms (attached).

That sounds like something that might be good to land for debugging future issues.

Comment 7

[Botond Ballo [:botond] [standards meeting Nov 4-9]]

(In reply to Timothy Nikkel (:tnikkel) from comment #6)

(In reply to Botond Ballo [:botond] from comment #5)

Since we don't have a layers dump with WebRender, I hacked the APZC tree dump to print the scroll nodes' transforms (attached).

That sounds like something that might be good to land for debugging future issues.

Yeah, I'm thinking of adding a "WebRender layer dump" of sorts that dumps the scroll nodes in UpdateHitTestingTree and prints many of the same properties we'd print for layers.