2.12 KB, text/plain
2.12 KB, text/plain
897 bytes, patch
rods (gone): review+
Marc Attinasi: superreview+
|Details | Diff | Splinter Review|
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.
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 :)
This worked fine on previous releases I assume, Theo?
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
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.
I am seeing this on 0.9.8 too.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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?
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.
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
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.
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!!!!!!
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.
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.
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!
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
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]
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 :-)
Assignee: colin → rods
Status: REOPENED → NEW
OS: OpenVMS → All
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+
Status: NEW → ASSIGNED
Summary: The printing file has PostScript prolog only. → [FIX]The printing file has PostScript prolog only.
Target Milestone: --- → mozilla0.9.9
Summary: [FIX]The printing file has PostScript prolog only. → [FIX]Values from prefs not initialized when prefs aren't there
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+
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)
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.
Keywords: nsbeta1 → nsbeta1+
*** Bug 125709 has been marked as a duplicate of this bug. ***
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
*** 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.