Steps to reproduce:

1. Navigate to https://slickdeals.net/f/13163905-net10-annual-5gb-plan-199-99-net10-annual-1gb-plan-149-99-tracfone-lg-rebel-3-w-1-year-49-99?page=2#commentsBox
2. Scroll through comments, move to next page if needed (it shows up within a page or two)

What happens:

Blurry/smudged looking text.

Expected result:

Sharp text

15:54.17 INFO: Last good revision: 855d557b82a20e1ed87af46bceac3b918534d37e
15:54.17 INFO: First bad revision: 431c5142ff3ad102328d90cb29470b20ccd1271e
15:54.17 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=855d557b82a20e1ed87af46bceac3b918534d37e&tochange=431c5142ff3ad102328d90cb29470b20ccd1271e

I haven't been able to reproduce this, yet. It's possible (but I think unlikely) that it will be resolved by https://bugzilla.mozilla.org/show_bug.cgi?id=1560499 when it lands (it's in the merge queue now). I'll keep trying to reproduce locally.

I have a minimal case that reproduces the issue. It appears to be related to snapping.

In this case, the external scroll offset of the scroll frame is a fractional value - I think this is causing issues as the picture caching code assumes that the scroll offsets will be rounded.

Is this expected behavior that WR should handle, or should the incoming external scroll offset be an integer value?

I think it should be fine to handle this in WR - with a combination of snap offsets + tweaking the picture content origin.

Gecko layouts typically produce a picture cache where the origin
of the picture rect is an integer. However, it can occasionally
be a fractional origin.

In these cases, we need to ensure the content origin is floored,
to maintain consistent snapping. When this case occurs, the UV
rect for the tile also needs adjusting, to ensure the exact
1:1 texel:pixel mapping when drawing the tile.

It's a little difficult to 100% verify that the bug is gone with this change - but I was able to reproduce it fairly reliably without this patch, and was unable to repro at all with the patch applied.

(In reply to Glenn Watson [:gw] from comment #2)

In this case, the external scroll offset of the scroll frame is a fractional value

Are these bugs somehow related? bug 1541072, bug 1528180, bug 1553818

I think in general we want rounding to happen as late as possible, because e.g. a scrollframe might be inside a transform and if we do rounding in APZ/Gecko and then the scrollframe gets scaled up in WR it will scroll jankily. So to me it seems to make sense to pass in the fractional scroll offset to WR and then let it do the rounding if needed.

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

For verification purposes:

• @Glenn, could you provide the test case mentioned in comment 2? (since we where unable to reproduce the issjue at all)
• after checking multiple pages with 69.0b11 on Windows10/macOS 10.13 the issue did not manifest at all with webrender on/off.

The minimal test case I was referring to was a wrench (standalone webrender test tool) test file, not a HTML file viewable in Firefox, sorry.

If you still want to try and verify it, I found that setting layout.css.devPixelsPerPx to 1.0 and scrolling through the URL in the first comment was usually enough for me to see the bug in the broken builds before it was fixed.

It does differ in how reproducible it is based on screen resolution + platform + GPU (Intel integrated GPU + Linux seemed to reliably show the problem for me), so it might be hard to verify conclusively.

Hello,

Unfortunately, because of our hardware restrictions we can't reproduce this issue or confirm that the bug is fixed. I will remove the qe verify+ flag. If somebody has the hardware necessary to reproduce this, they are more than welcomed to verify the fix.