Running the geckoview example app with webrender enabled, on bugzilla.mozilla.org only the top-left quarter (not actually exactly a quarter) of the page is visible to begin with. The rest of the screen just shows the background color.

As you zoom in, the visible area of the page increases slightly faster than the rate of zooming, revealing more of the page.

This seems to be a regression from bug 1521644, so I'm a wee bit surprised I haven't ran in to it before.

Similar looking bugs:

• bug 1561215 / bug 1520096
• bug 1554861

To me, looks pretty much same as bug 1561215, but interestingly different regressions...

Kats and I looked into this. The problem is that we have a clip in the WebRender display list that's scaled by the resolution but shouldn't be.

(The effect of bug 1521644 is largely incidental. It just shuffled around what display items have what clips in a way that exposed this scaling issue.)

The clip rect is derived from the composition bounds, which is in units that
are outside the resolution, but it's applied to the ScrollFrame item which is
inside the resolution.

Hooray! Confirmed the patch in comment 6 fixes all failure reftests on WebRender for viewport meta (bug 1520096).

Unfortunately, the patch regresses pinch-zoom-position-sticky.html on desktop (with WebRender): https://treeherder.mozilla.org/#/jobs?repo=try&tier=1&revision=60f3e16e5ba43910ee776de1fb8bc9f2a09ed3a8

The priority flag is not set for this bug.
:jbonisteel, could you have a look please?

For more information, please visit auto_nag documentation.

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

Unfortunately, the patch regresses pinch-zoom-position-sticky.html on desktop (with WebRender)

The change to the clip somehow results in us calculating a sticky offset of -333 where before it was 0.

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

The change to the clip somehow results in us calculating a sticky offset of -333 where before it was 0.

I debugged this a bit, but I don't want to go too deep down the rabbit hole here. In broad strokes, code for handling sticky elements in WebRender (or possibly code that populates its inputs in nsDisplayStickyPosition::CreateWebRenderCommands()) is confusing coordinates outside the zoom and coordinates inside the zoom.

This is a pre-existing bug that's uncovered by our clip change, and it appears to be specific to position: sticky. I suggest we mark the position: sticky test as failing for now on WR, and spin off a new bug for investigating this further, so we can go ahead and land this fix here, which unbreaks a much broader swathe of scenarios with WR + zooming.

WebRender handling of position:sticky is buggy in the presence of zooming.
The fix for bug 1563717 exposes this bug in pinch-zoom-position-sticky.html.

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

This is a pre-existing bug that's uncovered by our clip change, and it appears to be specific to position: sticky. I suggest we mark the position: sticky test as failing for now on WR, and spin off a new bug for investigating this further, so we can go ahead and land this fix here, which unbreaks a much broader swathe of scenarios with WR + zooming.

Filed bug 1569339 for the position:sticky issue.

https://hg.mozilla.org/mozilla-central/rev/5907e3987aff
https://hg.mozilla.org/mozilla-central/rev/0dd8f624159e

Hi guys, this issue still occurs in Nightly 70.0a1 (2019-07-28) only now it happens when the user Exits RDM mode, Please see the attached file. Should we log a new issue for it ?

Clearing needinfo as the issue described in comment 16 is tracked in bug 1569626.

I would recommend not uplifting this to 69 unless bug 1569626 is also fixed on 69.

Given where we are in the cycle, probably best to just let this fix bake and ride with 70.

This seems to be fixed now in the steady state which is great, but whilst zooming there still seems to be problems: it looks as if the correct value is calculated during painting but it doesn't get updated for the async zoom. You can reproduce this by zooming in to bugzilla.mozilla.org, then while you zoom back out again the bottom right of the screen is clipped and the clip "jumps around". It is also apparent if you are zoomed out then tap on the search box, then the bottom-right section gets clipped out as the page automatically zooms in.

Is that caused by bug 1569339, or should I file a new issue for that as well?

The issue you describe sounds unrelated to bug 1569339, which affects position:sticky elements only. Please do file a new issue - thanks!