Closed Bug 619272 Opened 11 years ago Closed 11 years ago
Intermittent failure in layout/reftests/css-import/290018-1
.html | image comparison (==)
16.37 KB, application/octet-stream
1.48 KB, patch
|Details | Diff | Splinter Review|
1.54 KB, patch
|Details | Diff | Splinter Review|
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1292383308.1292386591.27867.gz Rev3 WINNT 6.1 mozilla-central debug test reftest on 2010/12/14 19:21:48 Reftest log attached. Jonathan, do you think this is an instance of the bug you showed me yesterday? (can't find its bug number right now)
Yes, looks like it probably is. There's one faint AA pixel from the crossbar of the "t" that projects to the left of the origin of the text, and we're painting (or erasing, or clipping, or something) using a bounding box that doesn't include this pixel. The Windows version of the bug about this is bug 475968 (the Mac OS X equivalent is bug 476927). Not sure why this would be intermittent - perhaps a timing issue in relation to loading the stylesheet and (re)painting in response to the content and style changes that the script triggers?
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1292373253.1292376708.16038.gz Rev3 WINNT 6.1 mozilla-central debug test reftest on 2010/12/14 16:34:13 s: talos-r3-w7-018 You actually filed it on the second of two failures in a row (where the first was the second test run on the same cset, so not related to code, and a retest on the one you filed on went green, so at least it really is intermittent).
And that one that we double-starred? That's the third one on the same cset, which has now failed two of three.
Blocking reopening the tree, until someone overrules me. The story goes like this: http://hg.mozilla.org/mozilla-central/rev/abe884259481, a JS patch that certainly shouldn't affect text rendering only on Win7, landed on TraceMonkey, where this isn't happening, and then a short time later on mozilla-central. Then releng landed a build-directory shortening patch and some other stuff, which broke the tree. Two builds wound up being retriggered on abe884259481, and one reftest passed and the other was the first failure of this. http://hg.mozilla.org/mozilla-central/rev/f11f7ed625ba, the version bump after tagging for b8, landed, and that was the second failure of this. I got a couple more reftest runs triggered on it, and the first was green, but the second was the third failure of this. So on pushes that should have had absolutely nothing to do with this, it's failed 3 of 5 times on 3 different slaves. Something's really weird.
Severity: normal → blocker
OS: Mac OS X → Windows 7
I also saw this locally with a seemingly unrelated change. Adding a manual flush in the test before removing reftest-wait fixed things for me. Is this something which should be done with this test too?
We should land this. It ought to fix the bug. It's weird for those patches to cause it to fail, but whatever, we understand the bug. Let's work around it until we land the real fixes.
I think we can fix this failure by adding a bit of padding to the text, so that the antialiasing pixel doesn't project outside the frame. (This is just a band-aid for the failing test; the real issue is bug 475968, but that patch will need careful evaluation and testing as it has potentially far-reaching effects.)
Attachment #497748 - Flags: review?(roc)
Comment on attachment 497748 [details] [diff] [review] patch, add padding to the text to avoid potential clipping of antialiasing pixel This works too. PS, go to sleep.
Attachment #497748 - Flags: review?(roc) → review+
I'll land this, but I probably won't be around long enough to watch the tree...
Jonathan was faster! http://hg.mozilla.org/mozilla-central/rev/90b17476216d
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee: nobody → jfkthame
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.