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

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Theo Jakobus]

PWS500au, OpenVMS 7.3, DECMotif 1.2-6, MOZILLA 0.9.8.1 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

[Adrian Ulrich]

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

[Colin Blake]

This worked fine on previous releases I assume, Theo?

Comment 3

[Colin Blake]

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

Comment 4

[Theo Jakobus]

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

[Colin Blake]

I am seeing this on 0.9.8 too.

Comment 6

[Colin Blake]

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:

loadDialog*********************************************
toFileName              []
printToFile             false
print_frame             1
print_howToEnableUI     0
selection_radio_enabled false
print_howToEnableUI: 0
onAccept*********************************************
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
ALPHA$DKA100:[POSIX_SCRATCH_M098DBG]_1_18F93_NSGLOBALWINDOW.CXX;1, line 127452
nsWidget::~nsWidget() of toplevel: 22 widgets still exist.
WEBSHELL- = 3
we don't handle eBorderStyle_close yet... please fix me
WEBSHELL+ = 4

PreWidth = 8.500000 PreHeight = 11.000000

Width = 612 Height = 792
dpi 72.000000 top 0 bottom 0 left 0 right 0
###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(NS_OpenURI(getter_AddRefs(in),
uri))) failed: '(!((NS_OpenURI(getter_AddRefs(in), uri)) & 0x80000000))',
file ALPHA$DKA100:[POSIX_SCRATCH_M098DBG]_1_1671D_NSPOSTSCRIPTOBJ.CXX;1,
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

[Colin Blake]

Here's one problem, I think:

http://lxr.mozilla.org/seamonkey/source/content/base/src/nsDocumentViewer.cpp#40
96

donePrinting is not initialised to PR_FALSE.

But it doesn't fix my problem.

Comment 8

[Colin Blake]

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

[Colin Blake]

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

[Colin Blake]

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

[Colin Blake]

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

[Colin Blake]

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
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsSimplePageSequence.cpp#826
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

[Theo Jakobus]

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!

Comment 14

[Colin Blake]

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]

Comment 15

[Colin Blake]

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

http://lxr.mozilla.org/seamonkey/source/gfx/src/nsPrintOptionsImpl.cpp#499

499     PRBool b;
500     prefs->GetBoolPref(kPrintEvenPages, &b);
501     aPS->SetPrintOptions(kOptPrintEvenPages, b);
502 
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

[Colin Blake]

-> rods

Comment 17

[timeless]

Attachment: check for success

Comment 18

[rods (gone)]

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

Wow, thanks for the digging and finding the problem. r=rods

Comment 19

[Marc Attinasi]

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...

Comment 20

[timeless]

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

[Colin Blake]

Well, at the moment the default is coded into the ctor
http://lxr.mozilla.org/seamonkey/source/embedding/browser/photon/src/nsPrintSett
ingsImpl.cpp#77
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.

Comment 22

[Kevin McCluskey (gone)]

Marking nsbeta1+

Comment 23

[Christoph Gartmann]

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

Comment 24

[rods (gone)]

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.

Comment 25

[rods (gone)]

verified

Comment 26

[Colin Blake]

*** Bug 129833 has been marked as a duplicate of this bug. ***