If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Need at least one printer driver installed at one of the test machines



Release Engineering
10 years ago
4 years ago


(Reporter: Martijn Wargers (dead), Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



10 years ago
See bug 396024, comment 15 and onwards.
I made the tree orange, because the test which I checked in, failed, while it worked locally.

It turns out that the machines that failed don't have any printer drivers installed, and because my test relied on that, an error message came up.

I can improve my test to not throw or spew error dialogs when no printers are installed, but the test can only be useful when at least one printer is installed.

So I need to have one printer installed on one of the test machines that do Mochikit tests.
Assignee: server-ops → nobody
Component: Server Operations → Testing
OS: Windows XP → All
Product: mozilla.org → Core
QA Contact: justin → testing
Hardware: PC → All
Version: other → Trunk
robcee manages these machines.
I'm not sure what the best course of action is here. Do we want a physical printer plugged into these machines? Is there a network printer we can use? What about a file-based printer driver? If we had something like that, (e.g, Acrobat Writer) we could use it. Preferably something Free'n'Open-Sourced, of course.

Opinions and suggestions requested!
14:03 < shaver> http://www.mabuse.de/tech-vprinter.mhtml
14:04 < shaver> http://www.programurl.com/software/virtual-printer-driver.htm
14:04 < shaver> which produces images, so we could reftest printing too!

Comment 4

10 years ago
Maybe useful, I saw this printer driver which is GPL:
Although this is windows only.

Comment 5

10 years ago
Ok, I changed the mochitest for bug 396024 so that it is a Todo when there's no printer installed on the machine.
So that mochitest is active now, and will start testing as soon as a printer driver is installed on any of the test machines.

Comment 6

10 years ago
Never mind, I had to disable the test for bug 396024 again, because it failed on the Mac.

Comment 7

10 years ago
Sorry for spam, test for bug 396024 checked in again (and this time it sticked).

Comment 8

10 years ago
From bug 407080, comment 13:
This was busted on the FF Linux box and also my own box.  There's always a
print-to-file printer available on Linux (postscript and now PDF).  The FF
linux log is at

So apparently, this is already working on linux (otherwise the test could not be busted with the check-in of bug 407080.

Not sure if there's still a thing to do here.
Ideally, one would have the ability to print/print preview on Mac and windows, too, I guess.

Comment 9

10 years ago
Martijn on mac, you always have an option to print to PDF from the Firefox Print menu.  I don't know if you can get to this functionality from inside (or even outside) chrome though. I can help you research that if it would be of use...


Comment 10

10 years ago
Created attachment 311068 [details]
script to print pdf

This is the script that I use to print to pdf. Does that work on the Mac, without having a printer installed?

Comment 11

10 years ago
(In reply to comment #10)
> Created an attachment (id=311068) [details]
> script to print pdf
> This is the script that I use to print to pdf. Does that work on the Mac,
> without having a printer installed?
I gave this a little whirl over here on my test leopard box (which has no printer installed).  I changed the path to print the PDF to the home directory of the current user, I enabled XPConnect priv's on the file, but it still didn't work.  Even having the dialog show up and me click on "save" didn't work.  The exitprintpdf (I enabled it to see if it made a difference) reported that it is not a function on nsIWebBrowserPrint. I debugged through this thing with Venkman, but didn't come up with any useful information. 

Let me know if there is anything else you'd like me to try.

Comment 12

10 years ago
Ok, it seems like you made the correct changes.
I'm sorry, I have no idea how things are working on the Mac platform. It seems like it's working completely differently. It seems to me, in an ideal world, those functions would work on all platforms in the same way. Or at least, it should be commented in the .idl file that certain stuff is not working on the Mac or something.
Mass move of Core:Testing bugs to mozilla.org:ReleaseEngineering. Filter on RelEngMassMove to ignore.
Component: Testing → Release Engineering
Product: Core → mozilla.org
QA Contact: testing → release
Version: Trunk → other
Component: Release Engineering → Release Engineering: Future
Martijn: is this still being investigated, or even still an issue with 3.5/m-c?

Comment 15

9 years ago
I don't know.
Afaicr, it turned out there was at least one test machine that had a printer driver of some kind installed (one of the linux box).
Found in triage.

Our more recent moz2 pool-of-slaves are setup consistent with each other, so the original cause of this bug (different test behavior on different machines) should no longer be a problem. Closing as FIXED.

From comment#12, there was also some changes to test, and all seems to be working? Please reopen if there is something still to do here.
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 17

9 years ago
So there are printer drivers installed on the machines?
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering


4 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.