User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:68.0) Gecko/68.0 Firefox/68.0

Steps to reproduce:

1. Open reddit.com/r/firefox
2. Request desktop site
3. Tap on a link
4. Zoom in

Actual results:

See the attached screenshot

Expected results:

To be determined

Responding to bug 1542832 comment 8, which concerned this rendering problem:

(In reply to csheany from comment #8)

Is Bug 1298218 related?

I'd like to test that theory, but I can't, at least not using mozregression:

• The bug reproduces in Firefox 63.
• In versions prior to 63, the STR are not really applicable, as the page behaves completely differently (due to the changes we made to position:fixed handling in 63): the comments + sidebar are reflowed into an increasingly narrow width so they can continue to fit the screen as you zoom in, until eventually they overlap and are unreadable.
• Bug 1298218 landed in Firefox 54.

This means that, unfortunately, we cannot get a useful regression range here.

On the plus side, this should be easier to debug than bug 1542832.

Speculatively moving to Web Painting on the theory that this has to do with the handling of fixed-position clips in FrameLayerBuilder (but that's just a theory).

Jamie, is this something you think you'll have time to look at?

Sometimes I see it like in the screenshot with the content completely clipped out, and sometimes I see it with some content in low precision. Which makes me think it could be a displayport calculation issue.

Not sure whether it's related, but I also see when zooming out that the semi-transparent black borders aren't rendered correctly. The content behind is painted instead while zooming, until the next paint happens. Seems like that could be a displayport issue too, that there isn't content to composite asynchronously.

I can't reproduce this in a local Fennec build from trunk.

I can reproduce it in the latest Firefox Preview nightly, which is based on a GeckoView from the 69 branch.

So, it seems that this was fixed by a recent patch on trunk. It would be interesting to find out which (so we can possibly evaluate uplift etc.), but unfortunately that's hard to do because we don't have any nightly builds that mozregression supports and that can reproduce the issue (the issue doesn't repro in GVE due to bug 1573207).

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

So, it seems that this was fixed by a recent patch on trunk. It would be interesting to find out which

It looks like it was bug 1565512, which fixed the related bug 1542832 on the same site as well.