[FIX]Values from prefs not initialized when prefs aren't there

VERIFIED FIXED in mozilla0.9.9



Printing: Output
16 years ago
16 years ago


(Reporter: Theo Jakobus, Assigned: rods (gone))



Firefox Tracking Flags

(Not tracked)




(3 attachments)



16 years ago
PWS500au, OpenVMS 7.3, DECMotif 1.2-6, MOZILLA Build ID: 2002020220, HP
LaserJet 4000 as network printer.

Printing the start page http://www.mozilla.org/start/ opens the Print Window and
writes the prolog to a scratch file without any content, so the printer shows
activity but isn't printing. I checked the scratch file it has the PostScript
Prolog only.

Outside MOZILLA printing is ok.

Comment 1

16 years ago
I had a problem, that the firmware of my (PostScript) printer crashed when i
tried to print a page in mozilla..

gv displayed just crap..

- After removing my ~/.mozilla (from a old build) it worked again fine..

hm.. the 4. time i'm writing that removing the old configfiles may help.. today :)

Comment 2

16 years ago
This worked fine on previous releases I assume, Theo?

Comment 3

16 years ago
I wonder is this is caused by the isWritable change (bug 124093)? Can you try
running with privs turned on? Or make sure you have write AND DELETE access to
the directory where the temporary ps file is created.

-> colin
Assignee: rods → colin

Comment 4

16 years ago
Printing works fine for MOZILLA 0.9.6 and 0.9.7 which I still have for fallback.
Printing doesn't work under SYSTEM account too.

Under OpenVMS temporary files are created in SYS$SCRATCH: which is equivalent to
SYS$LOGIN: we are using a subdirectory [.SCRATCH] which is owned by the user.

Comment 5

16 years ago
I am seeing this on 0.9.8 too.
Ever confirmed: true

Comment 6

16 years ago
Looking for some help from some printer folks. Here's the summary.

Printing doesn't work on OpenVMS, as of 0.9.8 (previous versions were fine).
The ps file contains the prolog and that's it (no pages).
If I run a debug version it works fine. So this is either timing related
or something uninitialized. But when running the debug version I see:

toFileName              []
printToFile             false
print_frame             1
print_howToEnableUI     0
selection_radio_enabled false
print_howToEnableUI: 0
frametype      0
numCopies      1
printRange     0
printerName    PostScript/default
startPageRange 1
endPageRange   1
printToFile    true
nsWidget::~nsWidget() of toplevel: 24 widgets still exist.
WARNING: DropTimeout proceeding without context., file
nsWidget::~nsWidget() of toplevel: 22 widgets still exist.
we don't handle eBorderStyle_close yet... please fix me

PreWidth = 8.500000 PreHeight = 11.000000

Width = 612 Height = 792
dpi 72.000000 top 0 bottom 0 left 0 right 0
uri))) failed: '(!((NS_OpenURI(getter_AddRefs(in), uri)) & 0x80000000))',
line 63964

Is that assertion at the end normal/expected?

Given that this worked up until 0.9.8, and ideas on where I should look for
the breakage? I put some print statements into PrintDocContent and there are
no kids. Normal?

Comment 7

16 years ago
Here's one problem, I think:


donePrinting is not initialised to PR_FALSE.

But it doesn't fix my problem.

Comment 8

16 years ago
I defined DEBUG_PRINTING in nsDocumentViewer, and also added a couple of print
statements to PrintDocContent. In case it means anything to anyone:

DC 0 0 0 3DD2320 3D1D158 0 0 0   -1   0,0,0,0
DC 1 0 0 3DD2320 3D1D158 0 0 0   -1   0,0,0,0
DC 1 0 0 3DD2320 3D1D158 0 0 3EADDE4   -1   0,0,0,0
**CRB PrintDocContent aPO=64824096
**CRB PrintDocContent mHasBeenPrinted=0
**CRB PrintDocContent IsPrintable=1
**CRB PrintDocContent(a) donePrinting=0
**CRB PrintDocContent(b) donePrinting=0
**CRB PrintDocContent kid count=0
**CRB PrintDocContent aPO=64824096
**CRB PrintDocContent mHasBeenPrinted=1
**CRB PrintDocContent IsPrintable=1
**CRB PrintDocContent kid count=0

Comment 9

16 years ago
Created attachment 69106 [details]
printing.log when no pages appear in the ps file

Just read the code and saw that the debug output went into a file.

Comment 10

16 years ago
Created attachment 69118 [details]
printing log from when pages ARE printed

The only difference I can see in these printing.log files are addresses. Very
strange. Anyone any clues for me!!!!!!

Comment 11

16 years ago
Theo, here's your workaround to get printing working again.

Don't specify "All Pages" in the print dialog, instead use of page range of 1 to
999 or whatever.

Comment 12

16 years ago
Theo, if the previous workaround doesn't work, put these two lines in your
prefs.js file:

user_pref("print.print_evenpages", true);
user_pref("print.print_oddpages", true);

Rod and co: after picking up the prefs at
printOddPages and printEvenPages are both zero in my non-debug build. Yet in my
debug build they are correctly set to 1 and 2.

Comment 13

16 years ago
Colin selecting page range didn't work.

Adding the lines: user_pref("print.print_evenpages", true);
                  user_pref("print.print_oddpages", true);
to the file prefs.js solved the bug!

Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 14

16 years ago
It doesn't SOLVE the bug, it just works around the bug. I think I'm homing in on 
the real bug now....

[also reopening bug, not sure when/how it got marked resolved/fixed]
Resolution: FIXED → ---

Comment 15

16 years ago
Found the bug. Uninitialized data. Must happen be non-zero on all platforms 
except OpenVMS. Here's the bad code:


499     PRBool b;
500     prefs->GetBoolPref(kPrintEvenPages, &b);
501     aPS->SetPrintOptions(kOptPrintEvenPages, b);
503     prefs->GetBoolPref(kPrintOddPages, &b);
504     aPS->SetPrintOptions(kOptPrintOddPages, b);

On a call to GetBoolPref, the return (b in this case) is only updated if the 
pref existed. The usual practice is to set the boolean to what you want 
the default to be before the GetBoolPref call. However, since we've already set 
the printer options in the ctor, I think the correct fix here is to only call 
SetPrintOptions if GetBoolPref returns PREF_OK (0).

Here's my fix:

    PRBool b;
    if (prefs->GetBoolPref(kPrintEvenPages, &b) == 0)
      aPS->SetPrintOptions(kOptPrintEvenPages, b);

    if (prefs->GetBoolPref(kPrintOddPages, &b) == 0)
      aPS->SetPrintOptions(kOptPrintOddPages, b);

Can someone check this in? Its a bug on EVERY platform waiting to bite. Rod, I 
think this was your code :-)

Comment 16

16 years ago
-> rods
Assignee: colin → rods
OS: OpenVMS → All

Comment 17

16 years ago
Created attachment 69420 [details] [diff] [review]
check for success

Comment 18

16 years ago
Comment on attachment 69420 [details] [diff] [review]
check for success

Wow, thanks for the digging and finding the problem. r=rods
Attachment #69420 - Flags: review+


16 years ago
Keywords: nsbeta1
Summary: The printing file has PostScript prolog only. → [FIX]The printing file has PostScript prolog only.
Target Milestone: --- → mozilla0.9.9


16 years ago
Summary: [FIX]The printing file has PostScript prolog only. → [FIX]Values from prefs not initialized when prefs aren't there

Comment 19

16 years ago
Comment on attachment 69420 [details] [diff] [review]
check for success

sr=attinasi, but it was my understanding that the pref should be in the pref
file, with the default value, so the call to GetBoolPref shoudl nto fail...
Attachment #69420 - Flags: superreview+

Comment 20

16 years ago
erm right. someone should write a patch to all.js note that i'm not interested 
in checking this patch in as is, if anything it should go in with the patch to 
all.js i'm sorry i didn't pay attention to the bug (i had before but was in a 
hurry when i wrote the patch -- it was to show that you shouldn't explicitly 
compare w/ 0)

Comment 21

16 years ago
Well, at the moment the default is coded into the ctor
Are you to remove that too?

At the very least the behavior should be defined, rather than random, if these 
prefs are not present for some reason.
Marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+


16 years ago
Blocks: 125709

Comment 23

16 years ago
*** Bug 125709 has been marked as a duplicate of this bug. ***

Comment 24

16 years ago
I commented the method, it was never my intention that we require these prefs to
be in a pref file, only that we allow folks to change them. All the other prefs
have there values properly initialized beforehand, so if getting the pref fails
they are set correctly.

Now, maybe we should check the success of all the call in case prefs start
clearing the the values. Open a new bug for that.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 25

16 years ago

Comment 26

16 years ago
*** Bug 129833 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.