Open Bug 388169 Opened 13 years ago Updated 11 years ago
IPrint Settings .idl uuid causes printing reftest failures on win32 firefox unit test tinderboxes
Changing the UUID in widget/public/nsIPrintSettings.idl causes the printing reftests to fail on the two win32 firefox unit test tinderboxen (qm-winxp01 and qm-win2k3-01). The test failures are persistant as long as the change is left in. Backing out the change causes the tests to succeed again. The specific test failures are: REFTEST UNEXPECTED FAIL (LOADING): file:///C:/slave/trunk_2k3/mozilla/layout/reftests/printing/blank.html REFTEST UNEXPECTED FAIL (LOADING): file:///C:/slave/trunk_2k3/mozilla/layout/reftests/printing/272830-1.html I first experienced this trying to check in a patch for bug 381631, and again trying to check in a patch for bug 315687. Eli Friedman was able to reproduce the effect checking in a uuid change by itself (see the sample url). I've examined some of the relevant build logs, but didn't see an obvious explanation for the test failures. I don't have access to a win32 build environment, so I can't reproduce the problem. CVS log for nsIPrintSettings.idl (to cross-reference checkin times): http://bonsai.mozilla.org/cvslog.cgi?file=/mozilla/widget/public/nsIPrintSettings.idl My first attempt to patch bug 381631: http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&maxdate=1182710000 My second attempt to patch bug 381631 and Eli's test: http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&maxdate=1183242000 My first attempt to patch bug 315687: http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&maxdate=1184443447
For a new example, see <http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&maxdate=1184522370>. This morning, I tried to patch bug 315687 again. For some reason, this triggered printing reftest failures only on qm-win2k3-01; qm-winxp01 stayed green. When I backed out the patch--reverting the uuid--qm-win2k3-01 went green, but the printing tests started failing on qm-winxp01. I tried clobbering in conjunction with my checkin, but it doesn't seem to be working on the unit test boxes. See bug 388223.
kherron: would you like me to check in sometime when people are around in #build?
Eli, if you want to do it, that would be fine by me. I probably couldn't try again until this weekend. Note Gavin indicated that only certain people could clobber the unit test systems.
This bug bit us again when I landed bug 193001. :(
Severity: normal → major
I don't know if this is a bug in the reftest harness or a RelEng bug (does a clobber fix it) or what.
Component: Testing → Reftest
Product: Core → Testing
QA Contact: testing → reftest
You need to log in before you can comment on or make changes to this bug.