1499015 - Background rendered in front on www.pangaeabern.ch

Status: VERIFIED DUPLICATE of bug 1503447

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

Description

[Martin Giger [:freaktechnik]]

Attachment: Screenshot from 2018-10-15 11.27.37.png

STR:
- Load https://www.pangaeabern.ch/

Expected result: coffee cup is shown as background to the "Reservation" section.

Actual result:

Coffee cup is always shown in front until you've scrolled past the "Reservation" section. See attached screenshot.

I can provide the GPU section of my about:support if required - I'm using a GTX 770 on Linux with the proprietary driver though.

Comment 1

[Michael Kohler [:mkohler]]

Also broken on my Mac Book Pro (Retina, mid 2015), so shouldn't be only your graphic card/drivers.

Comment 2

[Darkspirit]

bad = just wait a bit and the coffee pic is shown over everything else

mozregression --repo mozilla-inbound --good 2018-09-14 --bad 2018-09-16 --pref gfx.webrender.all:true -a https://www.pangaeabern.ch/
> 4:53.17 INFO: Last good revision: be6801cdeb537afa655bbd67d12ead8dc01c6c38
> 4:53.17 INFO: First bad revision: 302dcd8139426cfe25b9d2685800809c2d603658
> 4:53.17 INFO: Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=be6801cdeb537afa655bbd67d12ead8dc01c6c38&tochange=302dcd8139426cfe25b9d2685800809c2d603658

> 302dcd813942	Andrew Osmond — Bug 1485420 - Part 2. Make ClipManager trim clip chains which can be merged with the display item. r=mstange
> a3ea43b5e6d8	Andrew Osmond — Bug 1485420 - Part 1. Expose WebRender bindings to merge a clip rect with a display item. r=mstange

Comment 3

[Andrew Osmond [:aosmond] (he/him)]

The image [1] appears even without scrolling down the page. It is stored inside a div with a transform, which in turn is inside a div with a fixed position. If I remove the transform or fixed position, it seems to correct the problem. Additionally, not applying the clip optimization to the image itself also appears to correct the problem. Investigation continues.

[1] https://static.wixstatic.com/media/960d37e6303c48bca4481915762dec95.jpg/v1/fill/w_2722,h_1480,al_c,q_90,usm_0.66_1.00_0.01/960d37e6303c48bca4481915762dec95.jpg

Comment 4

[Emilio Cobos Álvarez (:emilio)]

(In reply to Andrew Osmond [:aosmond] from comment #3)
> The image [1] appears even without scrolling down the page. It is stored
> inside a div with a transform, which in turn is inside a div with a fixed
> position. If I remove the transform or fixed position, it seems to correct
> the problem. Additionally, not applying the clip optimization to the image
> itself also appears to correct the problem. Investigation continues.

Note that bug 1498873 fixes problems with fixed positioning inside transforms and similar stuff, not sure if it affects the page here though.

Comment 5

[Andrew Osmond [:aosmond] (he/him)]

Emilio, I don't think it is related. I did apply your patch, but sadly it did not resolve the problem.

Another data point: If I disable APZ, while still applying the optimization, the problem goes away.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

(In reply to Andrew Osmond [:aosmond] from comment #5)
> Emilio, I don't think it is related. I did apply your patch, but sadly it
> did not resolve the problem.

Gah, too bad, I guess it was worth a shot, since that patch fixes a few clipping-related assertions in DL code :)

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

It appears that if we have only one clip in the clip chain, and we separate out the leaf, I changed the behaviour such that it will no longer set a scroll ID in the new ItemClips object it is applying. Ensuring we do the same thing in that case fixes the problem. Patch forthcoming...

Comment 8

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1499015 - Ensure we still apply a scroll ID if we optimize away the entire clip chain.

If we remove the leaf of the clip chain and merge it with the clip rect
of the display item, we only set a scroll ID if there was at least one
more item in the clip chain. If there was not, it was left unset.
Sometimes this results in the wrong scroll behaviour of an item, so if
we remove the entire clip chain, we should still set the scroll ID for
the ASR for the leaf.

Comment 9

[Andrew Osmond [:aosmond] (he/him)]

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a5956b65572d928c954831b90141fd8cbf8bebfb

Comment 10

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Reduced (related?) test case, v1

I didn't build this into a reftest yet because my patch didn't fix what I thought would be a reduced test case (non-WR and Chrome render as expected).

Comment 11

[Andrew Osmond [:aosmond] (he/him)]

(In reply to Andrew Osmond [:aosmond] from comment #10)
> Created attachment 9019441 [details]
> Reduced (related?) test case, v1
> 
> I didn't build this into a reftest yet because my patch didn't fix what I
> thought would be a reduced test case (non-WR and Chrome render as expected).

Seems to be the fixed element causing the problem.

Comment 12

[Andrew Osmond [:aosmond] (he/him)]

Turns out, the bug in my kind-of-reference test case is a regression from the summer:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d08944831e26fc9ec613e1fa2dc35d00332586ac&tochange=5b15326286d466b5cf4889160cc09b59bdde08fd

https://github.com/servo/webrender/compare/3829687ffbe8d55885d71a3d5e5e79216251548f...8e697f8cb1f1aab2e5f6b9b903eb7191340b10c5

Comment 13

[Dzmitry Malyshau [:kvark]]

Created https://bugzilla.mozilla.org/show_bug.cgi?id=1503447 for the WR API inconsistency with regards to clip and scroll nodes, which is relevant to this issue.

Comment 14

[Andrew Osmond [:aosmond] (he/him)]

Will follow up with this again once we finish the refactoring in bug 1503447. It will probably fix this problem implicitly.

Comment 15

[Andrew Osmond [:aosmond] (he/him)]

This got fixed by bug 1503447.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Fixed in 65 in bug 1503447.