This is a HTML+CSS-only photorealistic still life demo:
https://codepen.io/ivorjetski/pen/xMJoYO

There seems to be a weird extra yellow gradient in Nightly in the right corner of the rendered image besides the lemon. Firefox Stable renders the page as expected. See attachment for the artifact.

Huh, can you take a screenshot of the expected rendering? I can't see a difference between the chromium rendering / Nightly with WebRender on / release and your screenshot.

But I have very bad eye for these kinds of details, so... ;)

I saw this with webrender enabled.

Yeah, I only see this if I have webrender enabled. (I'm on Linux Nightly, where it's disabled by default)

I'm guessing the stray yellow gradient is something that's legitimately part of the page, but it's expected to be clipped or covered up -- and we've got some bug in our webrender backend that's breaking the clipping/stacking-order, which causes this area to be visible.

Confirmed on macOS. The bug disappears by changing line 1221 from filter: contrast(1.1); to filter: contrast(1);

Getting a reduced test case of this would be useful.

I've reduced the above linked codepen to a much more manageable one showcasing the bug: https://codepen.io/DivineGod/pen/YBOWXG

It's a combination of rotation and translation that pushes the bit out and overflow: hidden would normally clip it, but with contrast(1.1) that clipping doesn't happen

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0fcb85b4c2f2580df3de46af1c10b260dd156a44&tochange=f1dcdcc1674b19b6384f7354c4ac8a0f6896a1e5

Jeff, the regression window posted in comment 8 shows your patches. This is marked as a regression, is this something that you are looking into?

WebRender hasn't shipped yet, so even though this is marked as a regression it isn't one in the same sense. We don't have any indication that the problem here is widespread so we don't intend to block shipping on it.

Per comment 10, marking this fix-optional for 67.

Some notes from early investigation: gecko seems to be feeding things down reasonably well here. In the attached reduced test-case I demonstrate that 3d transforms aren't at all required, just a rotate(10deg); and a filter: contrast().

The existence of the contrast filter seems to mess up the clip management somewhere in the webrender backend. If I make a capture and edit the scene to be exactly the same but adjust the SetFilters to be an empty array the problem is fixed.

The problem is also common to basically every single FilterOp (sepia, contrast, saturation, invert, opacity, ...). I'm guessing something in picture building is messing up, but need to dig into the code now to fully understand what's going wrong.

Further notes for myself: as far as I can tell, by the time we get to the "builder" state (in wr-capture's terminology) everything still appears to be behaving correctly. The input degenerates into a picture(apply-clip)->picture(apply-filter)->picture(draw-rect), which all seems fine.

Pushed by ncsoregi@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/93c9a0e2da6e
properly apply transformed clips in brush shader. r=gw

Backed out changeset 93c9a0e2da6e (Bug 1527751) for wrench bustages

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=93c9a0e2da6e07fc65917024e20ab82cd4dc9805&selectedJob=234704224

Backout link: https://hg.mozilla.org/integration/autoland/rev/70baa37ae1eb12e2dec584fecf82453d6f4b17b4

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=234704224&repo=autoland&lineNumber=2787

task 2019-03-19T04:35:33.959Z] REFTEST reftests/filters/filter-saturate-red-alpha-1.yaml == reftests/filters/filter-saturate-red-alpha-1-ref.yaml
[task 2019-03-19T04:35:34.065Z] REFTEST reftests/filters/filter-saturate-green-alpha-1.yaml == reftests/filters/filter-saturate-green-alpha-1-ref.yaml
[task 2019-03-19T04:35:34.170Z] REFTEST reftests/filters/filter-saturate-blue-alpha-1.yaml == reftests/filters/filter-saturate-blue-alpha-1-ref.yaml
[task 2019-03-19T04:35:34.276Z] REFTEST reftests/filters/filter-hue-rotate-1.yaml == reftests/filters/filter-hue-rotate-1-ref.yaml
[task 2019-03-19T04:35:34.373Z] REFTEST reftests/filters/filter-hue-rotate-alpha-1.yaml == reftests/filters/filter-hue-rotate-alpha-1-ref.yaml
[task 2019-03-19T04:35:34.480Z] REFTEST reftests/filters/filter-long-chain.yaml == reftests/filters/filter-long-chain.png
[task 2019-03-19T04:35:39.075Z] REFTEST reftests/filters/filter-drop-shadow.yaml == reftests/filters/filter-drop-shadow.png
[task 2019-03-19T04:35:39.717Z] REFTEST reftests/filters/filter-drop-shadow-on-viewport-edge.yaml == reftests/filters/filter-drop-shadow-on-viewport-edge.png
[task 2019-03-19T04:35:40.139Z] REFTEST reftests/filters/blend-clipped.yaml == reftests/filters/blend-clipped.png
[task 2019-03-19T04:35:43.877Z] REFTEST TEST-UNEXPECTED-FAIL | reftests/filters/blend-clipped.yaml == reftests/filters/blend-clipped.png | image comparison, max difference: 51, number of differing pixels: 1192
[task 2019-03-19T04:35:43.881Z] REFTEST IMAGE 1 (TEST): data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAABNQAAAC5CAYAAADgbWIeAAAbTEl
[task 2019-03-19T04:35:43.886Z] REFTEST IMAGE 2 (REFERENCE): data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAABNQAAAC5CAYAAADgbWIe
[task 2019-03-19T04:35:43.886Z] REFTEST TEST-END | reftests/filters/blend-clipped.yaml == reftests/filters/blend-clipped.png

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

Attached updated reftest images for each of the failing tests.

Pushed by dluca@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/df43e036b44d
properly apply transformed clips in brush shader. r=kvark

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

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