This test is one that fails pretty consistently in my windows QR try pushes, and I can reproduce a failure on a loaner. So I'm going to target this test in the hopes that we can figure out what's going on with it.

That's the output from a specific run of this test on a loaner CI. You can view this by pasting the contents into https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml

This is a wr-capture of the test page on the same run as above. It was taken using the patch at https://hg.mozilla.org/try/rev/186dafae86bf5669d33679ca799279501b139c8b which basically triggers the WR capture mechanism after the canvas snapshot has been taken.

This is what I get when load the capture on OS X. This looks like neither what is the correct "expected" behaviour nor what the reftest analyzer showed as the erroneous test rendering.

The capture doesn't load for me on Windows, the wrench window hangs and Windows flags it as not responding. I was seeing this a few days ago on a different capture as well, I think it's a wrench bug. At any rate, the capture shows an incorrect rendering, but I don't know why. Dzmitry, could you help with the analysis of the capture? The page it's supposed to be rendering is layout/reftests/w3c-css/submitted/masking/mask-composite-2c.html but something somewhere went wrong (possibly on the gecko side in that the input to WR is wrong, or possibly somewhere inside WR). If you can narrow down where the problem might be that would help us find a fix for it.

On Windows, `set_title` hangs Wrench. I'll fix/work around that. On Linux, capture is replayed as expected and working correctly. MacOS is still to be investigated. What I see is that WR gets 4 image masks, provided by Gecko. The bug must be in the logic Gecko uses to compose those masks before passing to WR.

I looked a little closer and confirmed what Dzmitry said. In the scene-12-0.ron file, items 8, 11, 14, and 17 in the display list are the 4 mask clip items for the 4 squares on the test page. We can take their image ids - ((14), 10755) through ((14), 10758) inclusive - and look them up in backend.ron to find the raw blobs that correspond to them (blobs/5.raw, blobs/2.raw, blobs/3.raw, and blobs/7.raw, respectively). Those we can dump with xxd and see which bits are set and which are not. When I did this the bits I saw set corresponded to the blue areas on the test rendering, which seems to indicate that WR is properly using those masks on the display items and rendering what it thinks is the right thing. So the bug must be on the gecko side, where the masks are computed and sent over to gecko as textures. Maybe bug 1438631 will help but I'll keep poking at this.

This test seems to be consistently passing now, probably due to the changes in bug 1438631.