1) Go to: http://www.abc.net.au/news/2018-09-18/china-social-credit-a-model-citizen-in-a-digital-dictatorship/10200278 2) You see a video in full viewport 3) scroll down Expected: See the Article title block scrolling over the video and the next section (video) appear underneath/behind the title block. Actual: When scrolling down while webrender is enabled the page directly jumps to the next section without displaying the title at all. It is also not possible to scroll back up.

This is due to the rule: .Block-media.is-fixed { clip: rect(0,auto,auto,0); -webkit-clip-path: inset(0 0 0 0); } Fwiw making -webkit-clip-path -> clip-path (which we support) it works. So it smells like something related to the `auto` in that clip definition.

It works in non-WebRender, so the "auto" is probably unrelated. It's either a WebRender bug or a bug in WebRenderCommandBuilder's clip translation, I'd say. The clip property translates to a rectangle DisplayItemClip on the display item, whereas the clip-path property translates to an nsDisplayMask which translates to a WR image clip.

Debian Testing, KDE, Xorg, GTX 1060 Are elements just in the wrong order? Videos might not have played in "last good" because of bug 1482727. "Good" is when we see a white title on a black background, a video with people in boxes and are able to scroll down and then up again. mozregression --good 2018-04-15 --bad 2018-09-19 --pref gfx.webrender.all:true -a http://www.abc.net.au/news/2018-09-18/china-social-credit-a-model-citizen-in-a-digital-dictatorship/10200278 > 11:29.87 INFO: Last good revision: b0c68c17915159517e82c04b26801ff3869f61be > 11:29.87 INFO: First bad revision: 573a198b7fdf076e27eb1f468162df101246d7b3 > 11:29.87 INFO: Pushlog: > https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b0c68c17915159517e82c04b26801ff3869f61be&tochange=573a198b7fdf076e27eb1f468162df101246d7b3 > 573a198b7fdf Jean-Yves Avenard — Bug 1435212 - Add support for FFmpeg 4.0. r=bryce mozregression --repo mozilla-inbound --good 2018-04-18 --bad 2018-04-19 --pref gfx.webrender.all:true -a http://www.abc.net.au/news/2018-09-18/china-social-credit-a-model-citizen-in-a-digital-dictatorship/10200278 > 10:57.31 INFO: Last good revision: b0c68c17915159517e82c04b26801ff3869f61be > 10:57.31 INFO: First bad revision: 573a198b7fdf076e27eb1f468162df101246d7b3 > 10:57.31 INFO: Pushlog: > https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b0c68c17915159517e82c04b26801ff3869f61be&tochange=573a198b7fdf076e27eb1f468162df101246d7b3 > 573a198b7fdf Jean-Yves Avenard — Bug 1435212 - Add support for FFmpeg 4.0. r=bryce Let's disable ffmpeg... mozregression --repo autoland --good 2018-04-18 --bad 2018-04-19 --pref gfx.webrender.all:true media.ffmpeg.enabled:false -a http://www.abc.net.au/news/2018-09-18/china-social-credit-a-model-citizen-in-a-digital-dictatorship/10200278 > 2:00.03 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect. everything is good, wtf? mozregression --good 2018-04-15 --bad 2018-09-19 --pref gfx.webrender.all:true media.ffmpeg.enabled:false -a http://www.abc.net.au/news/2018-09-18/china-social-credit-a-model-citizen-in-a-digital-dictatorship/10200278 > 1:16.15 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect. This page is fine in today's Nightly with WebRender if I disable media.ffmpeg.enabled. I don't need to restart Nightly. What is going on?

No, the videos should be hidden by the clip that wraps them, not by elements on top that cover them. I don't know what the relation to ffmpeg is.

> Videos might not have played in "last good" because of bug 1482727. This assumption might be wrong. "last good" looks the same as disabling media.ffmpeg.enabled today. Videos are just static images then, the rest of the page looks okay.

Win10, GTX 1060 Windows was already bad on 2018-01-15. If I disable media.wmf.enabled or media.mp4.enabled, videos are just static images, but the page looks otherwise fine.

Nightly 20180920100522, left=non-WR, right=WR

Win10, GTX1060 mozregression --good 2017-04-10 --bad 2017-07-10 --pref gfx.webrender.enabled:true -a http://www.abc.net.au/news/2018-09-18/china-social-credit-a-model-citizen-in-a-digital-dictatorship/10200278 -a about:support > 3:36.64 INFO: Got as far as we can go bisecting nightlies... > 3:36.64 INFO: Last good revision: 95543bdc59bd038a3d5d084b85a4fec493c349ee (2017-06-19) > 3:36.64 INFO: First bad revision: 7a6baa6cca3292e8099e652b64d27e74df560874 (2017-06-20) > 3:36.64 INFO: Pushlog: > https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=95543bdc59bd038a3d5d084b85a4fec493c349ee&tochange=7a6baa6cca3292e8099e652b64d27e74df560874 [...] > 5:46.50 INFO: There are no build artifacts on inbound for these changesets (they are probably too old).

Turning off APZ seems to fix this somehow, at least on my macOS build.

I was able to reproduce the problem. The problem is addressed with latest nightly for me. It seems to be addressed with the following. https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e58fd91eddcdbdf00c8a1902026c1d4fe0845396&tochange=669cd919724934a05579ed2e561d04dedd11e93a Bug 1507848 https://github.com/servo/webrender/pull/3315

:alberts, can you still reproduce the problem with latest nightly?

Works like a charm!