Closed Bug 455423 Opened 12 years ago Closed 10 years ago
Painting error with -moz-transform rotate and large translate
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
OS: Windows XP → All
Hardware: PC → 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.
OS: All → Windows XP
Hardware: All → PC
(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.
OS: Windows XP → All
Hardware: PC → All
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?
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
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.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.