User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

1. Visit https://www.newstatesman.com/why-trust-science-naomi-oreskes-review
2. Scroll up and down the page beneath the image a few times
3. Look for 1px horizontal lines will flickering on the screen

Actual results:

Horizontal lines flicker on the page. This occurs on several different websites. Reproduced on both 13" and 15" MacBook Pro models as well as Mojave and Catalina.

Expected results:

No rendering artifacts.

Build ID 20191030021342
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:70.0) Gecko/20100101 Firefox/70.0

I didn't managed to reproduce this issue on Release(70), Beta(71) or Nightly(72) version, either on Mojave or Catalina using a MacBook Pro 15". I've tried also to reproduce it on High Sierra and on different hardware (iMac).

Could you please provide more information related to this issue? Could you try to reproduce this issue using a new profile? You can find more information here: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

(In reply to Cristian Craciun from comment #2)

...

Build ID 20191111170815
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0

I created a new test profile and found that the issue still occurs (also on the default profile).

Additionally, I found that the line appears and disappears when the width of the window is resized but seems to always happen in fullscreen (see the newly attached video).

Note that this glitch doesn't always appear when visiting the page but I can consistently reproduce it.

The position window.scrollY where the line appears continuously doesn't seem to be fixed.

I can confirm this issue, reproduced it on an MacBook Pro (retina, 15") on version 10.14 and version 10.15 using the latest Nightly 74.0a1, Firefox 72 and Firefox 73 beta 1. I could not reproduce this issue on Firefox 68.4.0 esr.

Please note that the issue is not reproducible when I disable the hardware acceleration from Preferences.

Last good revision: 9798d276348f91a467897783525134fe2b10723a
First bad revision: 8e2dfb26c66ce8f6a48bb1ba2f9d2a4ca6d884fe
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9798d276348f91a467897783525134fe2b10723a&tochange=8e2dfb26c66ce8f6a48bb1ba2f9d2a4ca6d884fe

Markus, could you please take a look over?

Hi Simona, can you still reproduce this with the latest Nightly? Here we cannot see it.

(In reply to Jens Stutte [:jstutte] from comment #9)

Hi Simona, can you still reproduce this with the latest Nightly? Here we cannot see it.

Yes, even if the issue is not as noticeable as it used to, I can still reproduce it on the latest Nightly 75.0a1 and MacBook Pro (Retina, 15-inch, Mid 2015). Resizing the browser's window makes the issue easier to reproduce - there is a horizontal line that flickers under the photo.

Please see the video:
https://imgur.com/a/aBuIi9e

I can reproduce it in fullscreen mode. Going to take a look.

At certain window widths, this testcase displays a blue horizontal line somewhere in the window.

It looks like the ImageLayer clip is offset / off-by-one somewhere.

This is caused by an OpenGL driver bug. The scissor rect does not intersect the viewport, but the closest edge pixels in the viewport still end up getting filled.

This does not reproduce when the discrete GPU is used.

We can work around it in the compositor - there's no need to draw when the clip rect doesn't intersect the viewport. But maybe we also need a workaround for WebGL.
Safari and Chrome show the same WebGL bug.

I have filed this bug with Apple as FB7642471.

For example, if the clipping rectangle has aClip.X() == 1024, then the normal for the clipping plane induced by the left edge of the clip will now be (1, 0, 0, -1024) rather than (0.0009765620343390458, 0, 0, -0.9999995231631829).

This change is mathematically valid:

• The dot products computed from these vectors become multiplied by planeNormal.Length() (compared to before this patch).
• The sign of the dot products is not affected, so the "intersection with plane" check is not affected:
  if ((nextDot >= 0.0) != (prevDot >= 0.0)) {
• The value of the dot products is only used to compute t, as follows:
  F t = -prevDot / (nextDot - prevDot);
  Here, the length now appears both in the numerator and in the denominator, canceling itself out.

As a result from this change, the existing tests no longer require integer nudging in order to pass.

Depends on D68702

The test added in this changeset is already fixed by the no-normalization change, but there are probably cases that require the explicit check that this patch adds.
When we were still normalizing the plane normals, the TransformAndClipBounds call in the added test was returning (1023.999878, 1023.999878, 0.000061, 0.000122).

Depends on D68703

These patches fix the bug because we will now return early from DrawGeometry at the destRect.IsEmpty() check in the problematic case. If the clip does not intersect the render target, we pass an empty aClip to TransformAndClipBounds, so we will now get a destRect that's guaranteed to be empty after these patches.

https://hg.mozilla.org/mozilla-central/rev/e51404852968
https://hg.mozilla.org/mozilla-central/rev/37a849a3f226
https://hg.mozilla.org/mozilla-central/rev/ac2c160ca492