Mozilla 1.0RC1 (Build ID 2002041711), Linux (SuSE 7.3) Mozilla always prints in Portrait mode, even when set to Landscape.

Confirming. Simply opening the print dialog (and then cancelling) resets the page setup to portrait mode... This was working in trunk build 2002-03-15-08, but is broken in 2002-03-18-06.

can't reproduce it here - 1.0RC1, Linux

I'm very surprised you can't because looking at the code I see no way this could possibly work... This got broken by rods' big printSettings rewrite. Now nsPrinterEnumeratorGTK::EnumeratePrinters unconditionally sets the orientation on aPrintSettings based on the current pref value. Since page setup never updates any pref values (a separate bug, only somewhat relevant here), we end up with an orientation of "portrait" for all printers any time we go through the printer list. Any reason we cannot remove the code in EnumeratePrinters() completely? That solves the problem for me....

bz: Can you post a LXR URL of the code which causes this, please ?

Sure thing. Postscript module: http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsDeviceContextSpecG.cpp#902 Xprint module: http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsDeviceContextSpecG.cpp#779 (this latter does not use prefs, but still clobbers the orientation value set in the printsettings...)

Get me a patch and I will try to get it in...

Taking...

AFAIK (please correct me) the current code is correct - InitPrintSettingsFromPrinter() fills the nsIPrintSettings object with the printer defaults. The problem is that the GUI code does not always set the orientation. There are (at least) two solutions for this issue: 1. Per-printer |nsIPrintSettings| objects - each printer gets it's own one. |nsIPrintSettings| gets a |boolean| member to set whether |InitPrintSettingsFromPrinter()| was called yet or not. If |InitPrintSettingsFromPrinter()| was called for this |nsIPrintSettings|-object then the function should behave like a NO-OP (no operation). OR 2. Add a string to |InitPrintSettingsFromPrinter()| with the name "lastPrinterNameInitalized" (or a better name :) to store the name of the printer |InitPrintSettingsFromPrinter()| was last called with. |InitPrintSettingsFromPrinter()| is a NO-OP if the old printer name passed to this method is the same as the current printer name argument (to avoid thath we reset user choices to the printer's defaults).

> 1. Per-printer |nsIPrintSettings| objects How would page setup actually work in this case? Would it just have to dump everything to prefs instead of storing it in the printsettings (this is a better idea anyway, imo -- page setup needs to be persisted across restarts). > 2. Add a string to |InitPrintSettingsFromPrinter()| with the name > "lastPrinterNameInitalized" Again, how does this interact with the page setup dialog (which does not have a printername associated with it....).

Boris Zbarsky wrote: > > 1. Per-printer |nsIPrintSettings| objects > > How would page setup actually work in this case? Would it just have to dump > everything to prefs instead of storing it in the printsettings (this is a > better idea anyway, imo -- Uhm, no. We would have one |nsIPrintSettings| per printer. |InitPrintSettings()| should only be called _once_ in the lifetime of a |nsIPrintSettings| (if there are |nsIPrintSettings| objects for each printer). If there is no printer name in the dialog then the currently selected one (or the default printer if there is no selection) should be used. > page setup needs to be persisted across restarts). Different issue (and do not get confused how the "printerfeatures" code is currently implemented) ... > > 2. Add a string to |InitPrintSettingsFromPrinter()| with the name > > "lastPrinterNameInitalized" > > Again, how does this interact with the page setup dialog (which does not have > a printername associated with it....). Well, see above. IMHO was not a good idea to make the "page setup" dialog not having a printer selection box since many options in this dialog depend on features of the printer (like orientation) or the selected paper size (which a per-printer attribute, too). Not all printers support "landscape" orientation and many support more than "portrait"/"landscape" - but our currerent dialogs do not reflect this (yet).

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

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

I think the only useable way is to use multiple global nsIPrintSettings objects (one per printer name) instead of one global nsIPrintSettings object and introduce a method which gets a printer name and returns the matching nsIPrintSettings object for it. If there is no nsIPrintSettings for this name yet then one instance gets created and the new object is initalised with InitPrintSettingsFromPrinter() ... rods ?

Recently I've found myself having a problem that may somehow be related to this bug, so I hope this is the right place for it (sorry if it's not). Some sites (like e.g. online shops) offer a separate, printer friendly version of the current page. It is shown in a separate window which is opened by JS window.open(). Decorations like the menu bar may have been turned off. The "Print..." dialog is opened by JS window.print() which is triggered by a button within that page. Under this circumstance, the user is not able to change to Landscape mode at all. There is no possibility to open the "Page Setup..." dialog.

This is a serious bug and should be fixed with a high priority. Right now, I need to go to a windows machine to print out something that only fits into a landscape printing mode, which is very annoying. I personnaly cannot tolerate the fact that a nice browser product like Mozilla 1.0 is shadowed by this ugly printing bug.

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

Marking this bug as a DUPlicate of bug 147605 ("Printing / Page settings reset themselves after print") ... *** This bug has been marked as a duplicate of 147605 ***

verified.