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


(Testing :: Reftest, defect, major)

Windows XP
Not set


(Not tracked)


(Reporter: kherron+mozilla, Unassigned)




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):

My first attempt to patch bug 381631:

My second attempt to patch bug 381631 and Eli's test:

My first attempt to patch bug 315687:
For a new example, see <>. 

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.