User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Navigate a page using CSS linear-gradient as page background.
Using a non-fresh Firefox profile - currently only seen under Windows.

CSS background property:
body {
background: #ffffff url(/media/images/bg.jpg) repeat-x;
background: #ffffff linear-gradient( 180deg, #214055 0, #274965 3.5em, rgba(0,0,0,0) 0);
background-repeat: repeat-x;
}

Actual results:

The linear gradient is rendered without respecting size indications. The rendering looks like the gradient area was stretched vertically to vertically fill the viewport height (e.g. when scrolling down the incorrect background stops at the page content position corresponding to 1 viewport height.

Only some browser profiles are affected.
Resetting the browser profile fixes the issue.

Expected results:

The linear gradient should be rendered correctly.

Note: rendering in Firefox's screenshot helper is correct on affected machine.

Setting gfx.webrender.force-disabled to true on an affected firefox instance (and restarting Firefox) lets the gradient be rendered correctly again.

Sounds like a webrender bug, given comment 3.

Nical, do you know why this might be?

(In reply to Jessie [:jbonisteel] plz needinfo (PTO until Dec 3) from comment #5)

Nical, do you know why this might be?

Not yet but it looks like the issue is in WebRender and not in the display list.

It appears to not be restricted to page backgrounds, but also any div when two gradient stops are at offset 100% (offset 1.0 in WR's display list).

This yaml test case inspired from the original one lets you reproduce the issue in wrench directly.

---
root:
  items:
    - type: gradient
      bounds: 50 50 500 500
      start: 0 0
      end: 0 100
      stops: [0.0, blue, 1.0, red, 1.0, green]

My understanding is that we should see a large green rectangle below a blue-to-red gradient but we see red instead.

This issue only happens with the gradient fast path which doesn't support hard stops and seems to detect them incorrectly.

Backed out for reftest failures on reftest.list

Backout link: https://hg.mozilla.org/integration/autoland/rev/284dc1d2f42b0586a9a629615aaff21234790e5d
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=278317500&repo=autoland&lineNumber=857

Backed out 3 changesets (bug 1596086) for causing wrench bustages on result.rs CLOSED TREE

Backout revision https://hg.mozilla.org/integration/autoland/rev/f816c8d32ca73321982c4bf3e13d16d53d707fad

Failed push https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=ad8db62e810c17911501f7ab03732a6f229c19fe&searchStr=wrench

Failure logs https://treeherder.mozilla.org/logviewer.html#?job_id=278522800&repo=autoland

Nicolas can you please take a look?

After applying logical reasoning and science I can only say that I guess a piece of the infra caught the flu. The wrench error says it fails to parse the added reference image but previous try runs and landings didn't have any problem with it and the commit adding the image hasn't changed since.
It also loads fine locally.

Try push (unchanged) didn't have the wrench bustage (except for the hg sparse checkout error that's been intermittently happening for a while), So I relanded this as is. https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=278088811&revision=41133fc3a4090b3eb2015bed76536b90a4890880

https://hg.mozilla.org/mozilla-central/rev/e4f0b7088d50
https://hg.mozilla.org/mozilla-central/rev/756b46d418e0
https://hg.mozilla.org/mozilla-central/rev/56e8f613024a