See testcase, when I click on the rotated textarea, it disappears (because of failed repainting or something like that). You can get the same painting bug, by moving a window over it.

Another case, in this case, the iframe becomes black.

Confirmed on Linux, on both testcases, via dragging another window over them. (clicking the testcases doesn't seem to trigger the bug on testcase 2, and it only occasionally triggers the bug on testcase 1) Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080914020418 Minefield/3.1b1pre OS/Platform --> All/All

Tentatively marking security-sensitive, as it looks like this might be reading uninitialized memory. (see upcoming screenshot)

The patterns in this looks like uninitialized memory to me.

I can't reproduce that screenshot, I'm more or less getting a normal painting error. There is no Firefox release yet out there, that has the -moz-transform feature in it. That's basically my criterium to file a crash bug as security sensitive or not. If it's not crashing on branch, it's not security sensitive.

(In reply to comment #5) > I can't reproduce that screenshot, I'm more or less getting a normal painting > error. Yeah -- that could be just because the memory we read is platform-dependent. (i.e. on windows, it hits an area that's initialized to 0's, but on Linux, it hits in-use memory) > There is no Firefox release yet out there, that has the -moz-transform feature > in it. Firefox 3.1b1 is coming up, though, and it's feasible that this bug won't be fixed by then, so I think it's better to initially leave this security-sensitive to protect beta-users. Setting as "sg:moderate?" after discussion with dveditz.

Here's testcase 2 with a larger iframe, so more corruption is visible at once. Playing around with this has shown that the corruption is mostly showing bits and pieces of other things on my screen. (i.e. pieces of other windows, files on my desktop, etc., *including* things I can't currently see because they're behind other windows.)

In the security review for the transform property we brought up issues with floating point overflows and it seems like that might be what's happening here. There's some code in nsStyleTransformMatrix that computes matrix products and I don't think that I did any bounds-checking on the resulting floats and nscoords. Would constraining these values to a certain range eliminate the problem?

These testcases all work for me on a current Linux trunk debug build. Do they still show problems for you?

Yes, they all seem to be wfm. Does this bug still need to be security sensitive?

WFM too, with today's nightly... Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a4pre) Gecko/20100405 Minefield/3.7a4pre ...and with a nightly from when this was initially filed... Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080915020438 Minefield/3.1b1pre (currently using Ubuntu 10.04 b1 up-to-date) I tried to reproduce with Compiz on and off, to see if that affected the old nightly's behavior, but I still couldn't repro. I wonder if that nightly becoming WFM is due to some Ubuntu system library changing? (In reply to comment #10) > Does this bug still need to be security sensitive? Hm, would you mind checking if it's reproducible on Windows with a nightly from around the bug-file-date? If it still is, I'd imagine we'd want to double-check that 3.5 & 3.6 branches are unaffected before opening this up.