156992 - Javascript function window.print() always uses Letter as page size

Status: VERIFIED WORKSFORME

(Core :: Printing: Output, defect, P3)

Description

[Martin Kavalar]

No matter what page size is selected in the print setup dialog, when printing is
called through javascript's print() function, letter is always the paper size
passed to the printer. This behaviour i could also verify on k-meleon compiled
against mozilla 1.0

Comment 1

[Martin Kavalar]

I got a little confused, mozilla 1.0 does not even have a dialog for setting the
page size, this is only found in k-meleon. 
When printing normally in mozilla it selects A4 (my printer default) as page
size, but when using window.print() i always get letter.

Comment 2

[Phil Schwartau]

Browser, not engine ---> DOM Level 0

Comment 3

[Johnny Stenback (:jst)]

Over to rods who deals with our printing code...

Comment 4

[:deanis74]

related to bug 118563?

Comment 5

[Roland Mainz]

This sounds like thaht the InitPrintSettingsFrom*()-functions aren't called in
this case.

Can anyone give me a "hint" where I can look for the code which gets called by
|window.print()| ?

Comment 6

[rods (gone)]

This doesn't make any sense to me because there really isn't any difference in
the code path once the "Print" method is called. And whether "Print" is called
from JS or the UI nothing with Page Size happens before that.

What is "k-meleon"

Comment 7

[Martin Kavalar]

k-meleon is the windows-version of galeon. Which are both browsers using the
gecko-engine that are supposed to be smaller and faster than mozilla. Basically
its phoenix without xul.

Comment 8

[Richard Trout]

I confirm this same problem on Windows 2000 and Moz 1.5. All other methods of
printing use printer defaults, but not windows.print(). Workaround - print
something else first, then windows.print() will follow that.

Remember that a large part of the world uses A4 not Letter!

Comment 9

[THOMAS, Renald]

I have the same problem on Windows 2000 and Moz 1.5.
When this bug will be fixed ?

Comment 10

[Martin Kavalar]

I updated the URL. Mozilla Firefox 0.9 still has the same problem.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Roland, see
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#2532 for
the window.print() code.

Basically, it calls GetGlobalPrintSettings() on the document viewer, and then
calls Print() on the document viewer with the return value of
GetGlobalPrintSettings().

Looks like nsPrintOptions::GetGlobalPrintSettings should init the global print
settings from the default printer or something....

Comment 12

[Frank M. Bauer]

I believe Bug 209369 describes the same problem.
This Bug is still alive and annoying as of Mozilla 1.7.1 and
Firefox 0.9 

Comment 13

[Frank M. Bauer]

There is a
nsPrintOptions::InitPrintSettingsFromPrinter(const PRUnichar *aPrinterName,
nsIPrintSettings *aPrintSettings)
that initialises the print settings correctly. 
However in the case of window.print()it is never called!
When printing via File->Print... it is called on the first printing occasion
before DocumentViewerImpl::Print(), nsPrintEngine::Print() etc.

Comment 14

[Martin Kavalar]

So why can't we get this fixed? It should be a one-line fix (just call
nsPrintOptions::InitPrintSettingsFromPrinter(const PRUnichar *aPrinterName,
nsIPrintSettings *aPrintSettings), how others have pointed out) which should not
be that hard. I'll be glad to do this, but it would really make more sense if
the person working on the code just added the line. Is there any way I can help?
How would i get the fix into the trunk if I did it?

Comment 15

[Frank M. Bauer]

Martin,
it might be advantageous to find out why the File->Print does it correctly and 
window.print() doesn't, eventhough they both are supposed to be javascript
functions and thus should behave similar. At least that is what I understood.
There might be a different problem than a missing call. The correct 
mechanism is there, just doesn't get used in window.print() case.
Unfortunatly, I did not understand enough to follow that through. 
Is there anybody out there who knows how that code works?

Frank

Comment 16

[Simon Paquet [:sipaq]]

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

Comment 17

[gekacheka]

SUMMARY:

From comparing what File | Print does to what javascript:print() does,
it looks like nsPrintOptionsImpl::CreatePrintSettings() needs to call
InitSettingsFromPrinter() (using GetDefaultPrinterName), in
order to fulfill the nsIPrintSettingsService spec.

DETAILS:

1.
javascript:print() calls GlobalWindowImpl.Print according to comment #11.
GlobalWindowImpl.Print calls GetGlobalPrintSettings
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#2561

2. 
File | Print calls PrintUtils.print()
http://lxr.mozilla.org/seamonkey/source/browser/base/content/browser-sets.inc#90
PrintUtils.print() calls PrintUtils.getPrintSettings(),
http://lxr.mozilla.org/seamonkey/source/toolkit/components/printing/content/printUtils.js#44
PrintUtils.getPrintSettings() calls GetGlobalPrintSettings via attribute
then calls PrintUtils.setPrinterDefaultsForSelectedPrinter().
http://lxr.mozilla.org/seamonkey/source/toolkit/components/printing/content/printUtils.js#143
PrintUtils.setPrinterDefaultsForSelectedPrinter()
calls nsIPrintSettingsService.initPrintSettingsFromPrinter and 
nsIPrintSettingsService.initPrintSettingsFromPrefs.
http://lxr.mozilla.org/seamonkey/source/toolkit/components/printing/content/printUtils.js#132

So it looks like maybe these init functions are the difference, but...

3. 
The spec for nsIPrintSettingsService says the GlobalPrintSettings
should be initialized from the default printer.
http://lxr.mozilla.org/seamonkey/source/gfx/idl/nsIPrintSettingsService.idl#50

4. 
nsIPrintSettingsService is implemented by nsPrintOptionsImpl
http://unstable.elemental.com/mozilla/build/latest/mozilla//gfx/dox/hierarchy.html

nsPrintOptionsImpl::GetGlobalPrintSettings calls 
nsPrintOptionsImpl::CreatePrintSettings
http://lxr.mozilla.org/seamonkey/source/gfx/src/nsPrintOptionsImpl.cpp#906

nsPrintOptionsImpl::CreatePrintSettings
does call InitSettingsFromPrefs, but does not call InitSettingsFromPrinter.
http://lxr.mozilla.org/seamonkey/source/gfx/src/nsPrintOptionsImpl.cpp#881


So it looks like nsPrintOptionsImpl::CreatePrintSettings needs to call
InitSettingsFromPrinter() using GetDefaultPrinterName() in order to fulfill the
nsIPrintSettingsService spec.  (This will take care of the requirement for both
nsIPrintSettingsService.globalPrintSettings and
nsIPrintSettingsService.newPrintSettings.)

Does this help?

Comment 18

[gekacheka]

Attachment: proposed patch nsPrintOptions::_CreatePrintSettings to call InitPrintSettingsFromPrinter (untested)

Maybe insert call to InitPrintSettingsFromPrinter something like below
http://lxr.mozilla.org/seamonkey/source/gfx/src/nsPrintOptionsImpl.cpp#926

926 nsresult nsPrintOptions::_CreatePrintSettings(nsIPrintSettings **_retval)
927 {
928   nsresult rv = NS_OK;
929   nsPrintSettings* printSettings = new nsPrintSettings(); // does not
initially ref count
930   NS_ASSERTION(printSettings, "Can't be NULL!");
931 
932   rv = printSettings->QueryInterface(NS_GET_IID(nsIPrintSettings),
(void**)_retval); // ref counts
933   if (NS_FAILED(rv)) return NS_ERROR_FAILURE;
934 
      PRUnichar * defaultPrinterName = nsnull;
      rv = GetDefaultPrinterName(&defaultPrinterName);
      if (NS_FAILED(rv) || !defaultPrinterName) return NS_ERROR_FAILURE;

      InitPrintSettingsFromPrinter(defaultPrinterName, *_retval);
      nsMemory::Free(defaultPrinterName);

935   InitPrintSettingsFromPrefs(*_retval, PR_FALSE,
nsIPrintSettings::kInitSaveAll); // ignore return value
936 
937   return rv;
938 }

Comment 19

[Pete Collins (MDG)]

Attachment: nsPrintOptionsWin.cpp

This is a patch we are working on. Note ::_CreatePrintSettings is called in
each platform implementation.

This patch doesn't work for me. Still trying to resolve.

Attachment 163372 [details] [diff] doesn't work for me.

Comment 20

[Pete Collins (MDG)]

Attachment: nsGlobalWindow.cpp

proposed patch. Tested and works for me on WinXP.

Needs some additional testing and review.

Comment 21

[Pete Collins (MDG)]

Comment on attachment 163445 [details] [diff] [review]
nsGlobalWindow.cpp

Adding Ben S for peer review

Comment 22

[gekacheka]

Does the nsGlobalWin patch fix this problem in the help viewer?

In firefox 1.0rc1
  Help | Help Contents | Print this page (toolbar icon)
also has this problem (letter instead of OS default A4).

(For testing on US windows, change default page size to A4 at OS level via 
  Start | Settings | Printers | context-click default printer | Printing Preferences
[bug 118563 comment 93])

Comment 23

[Benjamin Smedberg]

Comment on attachment 163445 [details] [diff] [review]
nsGlobalWindow.cpp

This is basically good, but I'd like to see a second draft:

>Index: dom/src/base/nsGlobalWindow.cpp

>   nsCOMPtr<nsIWebBrowserPrint> webBrowserPrint;
>   if (NS_SUCCEEDED(GetInterface(NS_GET_IID(nsIWebBrowserPrint),
>                                 getter_AddRefs(webBrowserPrint)))) {
>+
>+    nsresult rv;

Can you put this declaration at the top of the function? That is traditional.

>+    nsCOMPtr<nsIPrintSettingsService> printSettingsService = 
>+    do_GetService("@mozilla.org/gfx/printsettings-service;1", &rv);
>+    if (NS_FAILED(rv)) return rv;

Not-having this service shouldn't be fatal. Wrap the following code in if
(NS_SUCCEEDED(rv)) {}

>     nsCOMPtr<nsIPrintSettings> printSettings;
>-    webBrowserPrint->GetGlobalPrintSettings(getter_AddRefs(printSettings));
>+    printSettingsService->GetGlobalPrintSettings(getter_AddRefs(printSettings));
>+
>+    PRUnichar *printerName = nsnull;

Use nsXPIDLString and getter_Copies, and avoid the manual nsMemory::Free.

>+    printSettingsService->GetDefaultPrinterName(&printerName);

You need to null-check or rv-check this.

Comment 24

[Pete Collins (MDG)]

Attachment: nsGlobalWindows.patch

Comment 25

[Benjamin Smedberg]

Comment on attachment 163870 [details] [diff] [review]
nsGlobalWindows.patch

>Index: dom/src/base/nsGlobalWindow.cpp

>+    if (NS_SUCCEEDED(rv) && printSettingsService) {
>     nsCOMPtr<nsIPrintSettings> printSettings;

The whitespace is not quite correct, I am guessing this patch is -w ?

>-    webBrowserPrint->GetGlobalPrintSettings(getter_AddRefs(printSettings));
>+      printSettingsService->GetGlobalPrintSettings(getter_AddRefs(printSettings));
>+
>+      nsXPIDLString printerName;
>+      printSettingsService->GetDefaultPrinterName(getter_Copies(printerName));

Please wrap the following two calls with "if (printerName)"

>+      printSettingsService->InitPrintSettingsFromPrinter(printerName, printSettings);
>+      printSettingsService->InitPrintSettingsFromPrefs(printSettings, 

r=me, I also got moa=jst on IRC

Comment 26

[Pete Collins (MDG)]

Attachment: nsGlobalWindow.cpp

InitPrintSettingsFromPrefs doesn't use printerName.

So only below should be needed:

+      if (printerName)
+	 printSettingsService->InitPrintSettingsFromPrinter(printerName,
printSettings);

Yes, diff has -w flag

Comment 27

[Pete Collins (MDG)]

I would prefer if some folks can test out this patch before I check it in.

Thanks

Comment 28

[[e-mail]]

(In reply to comment #23)
>>+    nsCOMPtr<nsIPrintSettingsService> printSettingsService = 
>>+    do_GetService("@mozilla.org/gfx/printsettings-service;1", &rv);
>>+    if (NS_FAILED(rv)) return rv;
>Not having this service shouldn't be fatal. Wrap the following code in
>if (NS_SUCCEEDED(rv)) {}
Shouldn't we still print even if we can't get this service? And if we're not
interested in the failure, we should use the non-rv form of do_GetService and
null-check the result instead.

Comment 29

[Pete Collins (MDG)]

Yes, we should print either way. 

In either case, looks like an "else" is needed.

Comment 30

[Pete Collins (MDG)]

Attachment: nsGlobalWindow.patch [alt]

Here is an alternative that will print if there is failure obtaining the print
settings service.

It however adds more code bloat. I prefer attachment 163875 [details] [diff] [review].

Comment 31

[[e-mail]]

Comment on attachment 164377 [details] [diff] [review]
nsGlobalWindow.patch [alt]

sr=me if you indent do_GetService as it's a continuation line.

Comment 32

[Pete Collins (MDG)]

attachment 164377 [details] [diff] [review] checked in with whitespace fix. 

Comment 33

[[e-mail]]

Comment on attachment 163870 [details] [diff] [review]
nsGlobalWindows.patch

Cancelling request in favour of attachment 164377 [details] [diff] [review]

Comment 34

[Erik Fabert]

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

Comment 35

[OstGote!]

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

Comment 36

[Elmar Ludwig]

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

Comment 37

[THOMAS, Renald]

This Bug is still alive on Firefox 1.0.4 (with no patch), under Windows 2000.

Comment 38

[Martin Kavalar]

I can confirm this bug beeing alive again in Firefox 1.04 under Windows XP.

Comment 39

[Pete Collins (MDG)]

(In reply to comment #38)
> I can confirm this bug beeing alive again in Firefox 1.04 under Windows XP.

This fix was only checked in on the trunk. 

Comment 40

[xanthium1]

(In reply to comment #39)
> (In reply to comment #38)
> > I can confirm this bug beeing alive again in Firefox 1.04 under Windows XP.
> 
> This fix was only checked in on the trunk. 

When would a fix be expected for this? The problem is still apparant in version
1.0.6 for XP

Comment 41

[Pete Collins (MDG)]

This fix will either need to get checked in on the branch or when Firefox moves
over to the trunk, it will then be fixed.

Comment 42

[OstGote!]

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

Comment 43

[OstGote!]

This bug is fixed on trunk (Seamonkey 1.0/FF 1.1), so the resolution was
correct. But I let it open as dupe-catcher. If you want this on the branches,
request the flags or provide patches. Until you don't see a fixed1.7.x or
fixed-aviary1.0.x in the keywords, this bug is not fixed on the branches
(Mozilla 1.7.x/Firefox 1.0.x).   	

Comment 44

[Simon Paquet [:sipaq]]

Comment on attachment 163870 [details] [diff] [review]
nsGlobalWindows.patch

patch is obsolete

Comment 45

[Ben]

This bug is still alive on firefox 1.0.7 on windows XP - I can confirm on two systems.

Comment 46

[Tim Jackson]

I don't know if we are talking about the same thing but, but in Firefox 3.0.1 on Fedora Linux, window.print() still always prints as Letter and resets the "Paper size" option in Page Setup to "Letter" if it has been changed to something else. Is that this bug or should I open another?

Comment 47

[Justin Laing]

I think that's a separate issue. For Mac/PC this bug has definitely been fixed - we have 200+ customers that depend on this functionality using versions of firefox from 2.0 to 3.0.

Comment 48

[Ivan Baldo]

I can confirm this bug is present on Debian's Firefox (IceWeasel):
Mozilla/5.0 (X11; U; Linux x86_64; es-AR; rv:1.9.0.3) Gecko/2008092814 Iceweasel/3.0.3 (Debian-3.0.3-3)
You can use this HTML file to test:

<html>
<head>
<script type="text/javascript">
function printpage()
{
  window.print()
}
</script>
</head>
<body>
<p>First go to the File -> Page Setup option and select a weird paper size.</p>
<p>After that press this button <input type="button" value="Print"
onclick="printpage()" /> and save to a file.</p>
<p>Then use the File -> Print option and save to another file.</p>
<p>Both files should have the same weird paper size but the first one printed
with JavaScript just has Letter size.</p>
</body>
</html>

Comment 49

[Martin Vogel]

I can confirm this bug being well and alive in Firefox on Ubuntu 8.10: 
Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.10 (intrepid) Firefox/3.0.4

Comment 51

[Bart Friederichs]

I can confirm this bug is still well and alive in Ubuntu 9.04.

Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.9) Gecko/2009042113 Ubuntu/9.04 (jaunty) Firefox/3.0.9

Comment 52

[ockels]

Confirmed in Ubuntu 9.04 indeed, I also like to add that headers, margins & footer text settings are also affected 

ctrl+p works fine, but window.print(); ruins the initial settings. 

to reproduce:

If for example header & footertext are set to --blanco-- by default a web page printed with ctrl-p prints correct, a loaded page printed by javascript: window.print(), prints header and footer text.

Comment 53

[Sam Lown]

Also confirmed to still happen in Ubuntu 8.10 and 9.04. There doesn't seem to be any problem with printing on Mac OS X however.

Any chance of a fix soon?

Comment 54

[Sam Lown]

Tested in Firefox version 3.5b4 in Ubuntu 9.04 with the same effect.

For the sake of curiosity, I also tried the Gnome Epiphany web browser 2.26.1 (gecko-1.9) which did not not show the same issues despite having exactly the same dialogs.

Comment 55

[s3phy]

Happening to me with Firefox 3.0.11 on Ubuntu 9.04. This is definitely the worst bug I have with Firefox, as I frequently use webapps that prints using javascript...

Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.11) Gecko/2009060308 Ubuntu/9.04 (jaunty) Firefox/3.0.11

Comment 56

[Eko]

Same problem here:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

Comment 57

[Bart Friederichs]

It is getting worse.

Instead of just printing that one job in Letter, it changes the "Page Settings" to Letter.

Firefox 3.0.12 from Ubuntun 9.04

Comment 58

[Bart Friederichs]

Firefox 3.5.5 on Ubuntu 9.10 still has it. The paper size settings are not reset, everything looks fine. But, when printing, it still creates pages in US Letter format. Both the PS export and the real printing.

Comment 60

[Ritesh Khadgaray]

Also, I do see the orientation being reset to POtrait from landscape ( default ) .

Comment 61

[Neil Townsend]

I'm afraid to report that this bug seems present of Thunderbird 3.0 running on Win 2k. It seems to obsessively insist on all printers printing to letter, other programs seem to work fine printing to a4.

Thunder bird 3.0: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.

Comment 62

[Ritesh Khadgaray]

It seems, the settings are pulled from print.print_*, rather than from printer set by "print.print_printer" . Perhaps, the default printer settings needs to update print.print_* settings along with print.print_printer_name_* settings.

Comment 63

[Neil Townsend]

If I remove all the print.* settings from pref.js Thundebird still sets all printers to a4.

Comment 64

[Matěj Cepl]

Still present in Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100122 Fedora/3.6.1-1.el6 Firefox/3.6

Comment 65

[Matěj Cepl]

Not sure whether it is the same bug, or I should reopen new one, but another problem with window.print seems to be that it always prints in Portrait mode, without regards to settings in File/Page Setup.

Can very well reproduce on http://www.tizag.com/javascriptT/javascriptprint.php

Comment 66

[Daniel Holbert [:dholbert]]

The new issue in comment 65 looks like bug 546270, which has a patch that just got review.

Comment 67

[Daniel Holbert [:dholbert]]

Looks like the "[fixed on Trunk]" whiteboard status (added in comment 43 in 2005) was not correct, based on the followup comments and the fact that this bug is still open 5 years later.  Clearing whiteboard.

Comment 68

[Martin Stránský [:stransky] (ni? me)]

It's a dupe of Bug 156992, see https://bugzilla.mozilla.org/show_bug.cgi?id=546270#c14 for explanation. Generally it's caused by two different print handlers.

Comment 69

[RNicoletto]

This is WFM using testcase in comment 48 and in comment 65.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

Comment 70

[Ilja Sekler]

(In reply to comment #69)
> This is WFM using testcase in comment 48 and in comment 65.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914
> Firefox/3.6.10

WFM on Linux trunk (<http://hg.mozilla.org/mozilla-central/rev/29c228a4d7eb>), but the bug is perfectly reproducible using the current 1.9.2 branch on Linux.

Comment 71

[Jonathan Watt [:jwatt]]

(In reply to Daniel Holbert [:dholbert] from comment #67)
> Looks like the "[fixed on Trunk]" whiteboard status (added in comment 43 in
> 2005) was not correct, based on the followup comments and the fact that this
> bug is still open 5 years later.  Clearing whiteboard.

I think that was for Windows/Mac. Subsequent comments seem to have been about Linux.

At any rate, based on comment 70 and the fact there have been no subsequent comments in the last six years I assume the patch for bug 546270 or something else fixed this.

(FWIW I'd also note window.print is note widely used:)
https://www.chromestatus.com/metrics/feature/popularity#V8Window_Print_Method

Comment 72

[Matěj Cepl]

I can confirm, it truly seems like fixed.