Open Bug 388169 Opened 13 years ago Updated 11 years ago

Changing nsIPrintSettings.idl uuid causes printing reftest failures on win32 firefox unit test tinderboxes

Categories

(Testing :: Reftest, defect, major)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

People

(Reporter: kherron+mozilla, Unassigned)

References

()

Details

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.