Started to fail between http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1221230727.1221236442.9144.gz MacOSX 10.4 comm-central dep unit test on 2008/09/12 07:45:27 [ REFTEST TEST-PASS | file:///builds/slave/comm-central-macosx/build/mozilla/layout/reftests/bugs/244135-1.html | REFTEST TEST-PASS | file:///builds/slave/comm-central-macosx/build/mozilla/layout/reftests/bugs/244135-2.html | ] and http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1221236167.1221241792.23432.gz MacOSX 10.4 comm-central dep unit test on 2008/09/12 09:16:07 [ REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/comm-central-macosx/build/mozilla/layout/reftests/bugs/244135-1.html | REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/comm-central-macosx/build/mozilla/layout/reftests/bugs/244135-2.html | ]

"Between" m-c:5bd002995589 and m-c:d7c555ce0fc7: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-12+06%3A49%3A03&enddate=2008-09-12+08%3A38%3A05 [ dbaron@mozilla.com Fri Sep 12 08:38:04 2008 -0700 d7c555ce0fc7 Zack Weinberg — Bug 453566 - HTML element with rgba(0,0,0,0) background produces garbage on screen. r+sr=roc d426fd05130b Zack Weinberg — Bug 453916: treat transparency strictly as a special case of color alpha. r+sr=dbaron ]

Do you know if that test machine is PPC or x86?

First impression: I do not see this regression on Linux and I don't believe it can have been caused by my patches, because neither the test cases nor their reference renderings make any use of transparency. There might've been something I screwed up with the special "foreground" color flag, but these test cases and their references are being rendered in quirks mode, which sets the border-color for TABLE, TH, and TD to "gray", so that shouldn't be it either.

(In reply to comment #3) > Do you know if that test machine is PPC or x86? "Building on: cb-sea-miniosx01" (I always assume PC/x86, but) KaiRo should know for sure.

I could imagine things like compiler version or architecture differences in handling undefined behavior like shifts of signed integers into or from the high bit. (I think that's undefined, anyway, and we do it in a bunch of places in handling of the alpha component of RGBA colors...)

So these 2 tests pass on my PPC OS X 10.4 Mac.

What's in the mozconfig for that tinderbox?

Loading layout/reftests/bugs/244135-1.html under valgrind, I get: ==24416== Conditional jump or move depends on uninitialised value(s) ==24416== at 0x17FCF0DA: ProcessTableRulesAttribute(void*, nsRuleData*, unsigned char, int, unsigned char, unsigned char, unsigned char) (nsHTMLStyleSheet.cpp:192) ==24416== by 0x17FCF204: ColPostResolveCallback(void*, nsRuleData*) (nsHTMLStyleSheet.cpp:263) ==24416== by 0x17FDDEB8: nsRuleNode::WalkRuleTree(nsStyleStructID, nsStyleContext*, nsRuleData*, nsCSSStruct*) (nsRuleNode.cpp:1657) ==24416== by 0x17FDE843: nsRuleNode::GetBorderData(nsStyleContext*) (nsRuleNode.cpp:1369) ==24416== by 0x17FDE8F2: nsRuleNode::GetStyleBorder(nsStyleContext*, int) (nsStyleStructList.h:134) ....

For both lines 192 and 196, which, in my tree, are: if (NS_GET_A(borderColor) == 0 || foreground) { and borderColor = (NS_GET_A(borderColor) == 0 || foreground) ? NS_RGB(0,0,0) : tableBorderColor;

...though that's probably harmless (in this case, at least), because it's the result of GetBorderColor not initializing aColor when it sets aForeground to true.

Auditing for other problematic sites: IsSolidBorderEdge is buggy both before and after the patch. I should write a testcase for that as well. ProcessTableRulesAttribute is actually worse than I thought because on line 196 it uses the wrong variable. That's actually likely to be the cause of this test failure.

I'll land this in the morning; too late to watch the tree now (unless someone else wants to land it for me).

Actually, http://hg.mozilla.org/mozilla-central/rev/094602d1ccfc

(In reply to comment #12) > IsSolidBorderEdge is buggy both before and after the patch. I should write a > testcase for that as well. I filed bug 455105 on this.

Comment on attachment 338422 [details] [diff] [review] patch [Checkin: Comment 14] You've already landed this, but for the record, I looked at the code before bug 453916, and this is the right fix; it was using tableBorderColor before, and I should've realized that GetBorderColor only sets one of its out-parameters. And I've been compiling with --disable-optimize so of course I don't get uninitialized variable warnings. Should change that.

V.Fixed between http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1221275110.1221279957.24095.gz MacOSX 10.4 comm-central dep unit test on 2008/09/12 20:05:10 and http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1221279682.1221285322.5207.gz MacOSX 10.4 comm-central dep unit test on 2008/09/12 21:21:22