User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Build ID: 20190325095153

Steps to reproduce

1. Open Responsive Design Mode.
2. Make viewport long enough so a scrollbar appears on the side of the browser (not viewport).
3. Scroll up and down with that scrollbar.

Actual result
Viewport clips into titlebar. (Please refer to the attached video.)

Workaround
Disable WebRender.

System info
OS: Windows 10 1809
GPU: Nvidia GeForce GTX 760
Driver: 419.67 (released on 2019-03-25)

The regression range is https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7b26b83385998b30acad1feb4ee02a4059eaafe2&tochange=5fa1f6433408d804a98025029a3ed38260a81dce.
There are some WR bugs (bug 1529378, bug 1523080) and some in Graphics (bug 1521466, bug 1523080). Mozregression is not helpful further bisecting the regression range.

Kats, could this have been caused by bug 1523080?

It's possible, yeah. I can bisect with local builds to verify. Leaving needinfo on me for now.

Yup, it was caused by bug 1523080.

I investigated this a bit, and am not totally sure what's going wrong here. The clip on the Iframe WRDL item seems to be correct, and the rootmost stacking context on the content pipeline has a ClipId::root() as the clip_id. That gets translated to the Iframe's clip as intended by the iframe flattening process. So as far as I can tell the clip chain setup seems fine and the problem must be deeper in WR. However I'll take a closer look at a capture and see if I can figure out what's happening.

Some more notes:

1. Turning off APZ or at least setting apz.drag.enabled to false makes this easier to repro and debug. This also implies the problem is not specific to APZ and is about how WR is rendering the static display list.

2. After some digging I found what appears to be a bug, I think this line should be initializing mScrollId to wr::wr_root_scroll_node_id(). This was causing a couple of display items near the start of the list to have what appeared to be incorrect spatial IDs. However, making this change didn't fix the issue in this bug. I've kicked off a try push with that change anyway to see if it has any impact on reftests.

3. Pretty sure now the problem is deeper inside WR. The items inside the content pipeline's root stacking context don't have their clip set to the pipeline clip, but the root stacking context which encloses those items does, so they should really still be getting clipped just fine.

Dzmitry, do you have cycles to look into this? It would be much faster for you than it will be for me.

was able to repro on macOS (not linux), looking now

When a picture cache tile is dirty, we need to apply the local clip to items drawn there.

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