This is likely gonna be very vague. Currently, my Firefox looks like this: http://prntscr.com/ifq1g2 I have webrender and webrendest enabled. I can't tell whether they have anything to do with this. Since it's an occasional thing, I don't really have any steps to reproduce. You can find my about:support content here: https://pastebin.com/Vi3FweUf

Could be related to https://github.com/servo/servo/issues/20239

Tobias, do you still see this issue? Would be great to get a WR capture (folder "wr-capture" appears in the working folder of Nightly executable once you hit Ctrl+Shift+3).

(In reply to Dzmitry Malyshau [:kvark] from comment #2) > Tobias, do you still see this issue? Would be great to get a WR capture > (folder "wr-capture" appears in the working folder of Nightly executable > once you hit Ctrl+Shift+3). Since it happens so infrequently, I cannot be sure at this point. But I'll keep an eye on it and do what you told me when I see it.

I just got this issue again. However, pressing the above shortcut doesn't seem to do anything. I tried searching for a capture_webrender directory on my Mac, but it didn't find any. Any ideas? For now I'll keep my Nightly like this.

The way it currently works is that Firefox tries to create "wr-capture" folder in the working directory. If on Mac you launched Firefox from the menu, the working folder would not have permissions to create a folder. Please try launching it from terminal and then checking for this folder.

I was able to capture a wr-capture at the time of the bug. You can get it from http://tobbi.bplaced.net/krams/wr-capture.zip

Another one (for maybe cross-referencing or something): http://tobbi.bplaced.net/krams/wr-capture_2.zip

Thanks Tobias, I'm able to see the corruption on my side thanks to your captures. No idea why this happens, yet.

So far, it looks like a general failure of WR to keep its internal state consistent. Some texture arena or a freelist has gone wild, and we end up with a broken frame. It would be great to have some sort of validation logic in place that we'd use for captures received from the users.

Uploading the first WR capture investigation notes. The image item, entry, texture entry, and GPU block for UV coordinates all look good. I can think of two ways the logic can go wrong in this case: 1. since this is a blob image, the contents might have been obtained by the wrong source? i.e. the blob image handler/rasterizer provided by Gecko had internal failure 2. texture atlas allocation got wrong, and there is another element placed on the same texels. We need a validation routine to detect this.

Tobias can you still reproduce this?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #11) > Tobias can you still reproduce this? I cannot be certain since this happens once every few months at most. I haven't had this issue in a few months now, but that doesn't mean it's stopped occuring alltogether.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #11) > Tobias can you still reproduce this? I can still reproduce this. Just had the same issue again!

You're only seeing this on Mac right?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #14) > You're only seeing this on Mac right? Yes.