1255336 - Printing results in empty page with print.always_print_silent=true

Status: RESOLVED INACTIVE

(Core :: Printing: Output, defect)

Description

[gee]

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.10 Safari/537.36

Steps to reproduce:

Nothing.

https://hg.mozilla.org/mozilla-central/log/5f7c184ccd800b2ed512c23fb609007efd198eaf%3Ad6d81655dd9e146c300a64c0fcaeb04ca3300a19 changeset between 5f7c184ccd800b2ed512c23fb609007efd198eaf and d6d81655dd9e146c300a64c0fcaeb04ca3300a19 caused the problem.


Actual results:

when you print arbitrary page, it doesn't print.

Comment 1

[Bob Owen (:bobowen)]

Hi gee,

I've just tried printing a couple of different pages using Fx47 on Windows 7 (which is now on Aurora / Developer Edition) and it's is printing OK for me.
Is this the version you are using?
What version of Windows are you having the problem on?

Also, please could you give an example of a page that isn't printing for you and a bit more description about any error messages you are seeing.

Thanks.

Comment 2

[gee]

Using Windows 2003 and printing shows no error but empty page is printed. 
when you print a web page of n pages, i expect non-empty page of n pages, but i got n empty page.

Comment 3

[Bob Owen (:bobowen)]

(In reply to gee from comment #2)
> Using Windows 2003 and printing shows no error but empty page is printed. 
> when you print a web page of n pages, i expect non-empty page of n pages,
> but i got n empty page.

Thanks.

I don't have Windows 2003 set up, but I've just tried WinXP 64-bit, which I believe is the closet I have and I am getting an error although it seems different to yours.
I'll investigate that first.

My WinXP 32-bit VM printed fine.

Comment 4

[gee]

to #3, please try again with print.always_print_silent = true

Comment 5

[gee]

It print

Comment 6

[Bob Owen (:bobowen)]

(In reply to gee from comment #4)
> to #3, please try again with print.always_print_silent = true

Ah, that makes sense.

That is a hidden pref that will no longer work at the moment on Windows with e10s turned on.

The main problem is that it allows a web page to print without your permission, by simply using the JS window.print().

I'm working on patches in other bugs that should allow this option to work again.
So that if you print (e.g. by pressing Ctrl-P) it would print silently, but if a web page tried to print it would show the print dialog.

(I fixed the problem I was having on WinXP 64-bit.)

Comment 7

[Bob Owen (:bobowen)]

Jeff - this is a hidden pref, which no longer works with printing via the parent process.

It's hidden (so you have to add it to about:config yourself), but after searching for "always_print_silent", there seems to be a fair amount of instructions over how to do this.

We shouldn't need printing via the parent in 47, because the sandbox isn't turned on at the moment, so shall I turn it off?

My plan, with some other printing changes I'm doing at the moment, is to allow this pref to work in the future, but only when the print has been triggered by the user.

Comment 8

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Bob Owen (:bobowen) from comment #7)
> Jeff - this is a hidden pref, which no longer works with printing via the
> parent process.
> 
> It's hidden (so you have to add it to about:config yourself), but after
> searching for "always_print_silent", there seems to be a fair amount of
> instructions over how to do this.
> 
> We shouldn't need printing via the parent in 47, because the sandbox isn't
> turned on at the moment, so shall I turn it off?
> 
> My plan, with some other printing changes I'm doing at the moment, is to
> allow this pref to work in the future, but only when the print has been
> triggered by the user.

I think if it's simple to do so, we shouldn't regress this in 47. My gut says that there isn't likely very many users impacted by this even if we leave it as-is, but we should really try to keep compat between e10s and non-e10s in the same cycle if possible.

Fixing this and your other work should block sandboxing, correct?

Comment 9

[Bob Owen (:bobowen)]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #8)

> I think if it's simple to do so, we shouldn't regress this in 47. My gut
> says that there isn't likely very many users impacted by this even if we
> leave it as-is, but we should really try to keep compat between e10s and
> non-e10s in the same cycle if possible.

OK, trivial to do, so I'll sort that on Monday, thanks.
 
> Fixing this and your other work should block sandboxing, correct?

At least some of the other work already is, setting this to block as well.
I'll create a separate bug to land the patch for turning off the print via parent in non-Nightly.

Comment 10

[r.chrzanowski]

Currently trying to print with print.always_print_silent = true on e10s (FF47 and FF48) ends up with two dialogs:
Printer Error: An error occurred while printing.
and
Print Preview Error: An error occurred while printing.

I also have encountered problem with blank pages with always_print_silent on and without e10s a few days ago. Can't reproduce that anymore though.

Comment 11

[jscher2000]

On SuMo, a user reports getting blank output in Firefox 46.0 on Windows 8.1 with an Epson TM-T88V receipt printer. It does not appear e10s is enabled. It's fine with Firefox 45.0.2. Anyone want to ask a question there, or just suggest filing a new bug?

https://support.mozilla.org/questions/1120310

Comment 12

[Bob Owen (:bobowen)]

(In reply to jscher2000 from comment #11)
> On SuMo, a user reports getting blank output in Firefox 46.0 on Windows 8.1
> with an Epson TM-T88V receipt printer. It does not appear e10s is enabled.
> It's fine with Firefox 45.0.2. Anyone want to ask a question there, or just
> suggest filing a new bug?
> 
> https://support.mozilla.org/questions/1120310

This must be a different bug.
The only thing I can think of is that the print settings from the prefs are overriding the printer ones and they are now invalid.

Can you ask them for the prefs which start "print.printer_" and then the printer name and file a new bug thanks.

Comment 13

[r.chrzanowski]

I have found that blank pages appear when printing silently because with always_print_silent = true Firefox cares for print.printerName_resolution preference. When that preference is wrong (for ex. negative) blank page is printed. 
With always_print_silent = false Firefox ignores resolution and prints with printer's default one. 

Found that when realised that initPrintSettingsFromPrefs (http://doxygen.db48x.net/mozilla/html/interfacensIPrintSettingsService.html) inits settings as -437918235 when its preference doesn't exist.

Comment 14

[Bob Owen (:bobowen)]

(In reply to r.chrzanowski from comment #13)
> I have found that blank pages appear when printing silently because with
> always_print_silent = true Firefox cares for print.printerName_resolution
> preference. When that preference is wrong (for ex. negative) blank page is
> printed. 
> With always_print_silent = false Firefox ignores resolution and prints with
> printer's default one. 

Thanks, yes, it appears that the code path used when the hidden pref is set has always been a bit broken.
It doesn't save all of the details the first time it gets information from the printer and then it overwrites things that it has saved with the prefs.
It does get information from the printer again, but doesn't set the resolution the second time.
To enable printing via e10s we now have to use more information from the settings.

I didn't pick this up from the original reporting, because I knew that I had broken printing silently with printing via the parent, which we haven't shipped yet.
If you've printed without always_print_silent first then the resolution gets stored in the prefs and it then works when you enable it.

I'll work out a fix for this and file the print via parent problem as a separate bug.

Comment 15

[Bob Owen (:bobowen)]

[Tracking Requested - why for this release]:
Regression when using hidden pref print.always_print_silent

Comment 16

[Bob Owen (:bobowen)]

Attachment: MozReview Request: Bug 1255336: Copy DEVMODE details back to print settings in GetDataFromPrinter. r?jimm

nsDeviceContextSpecWin::GetDataFromPrinter is only called with print settings, when the settings aren't properly populated in nsDeviceContextSpecWin::Init.
This only happens when printing silently and the print settings have last been populated with prefs.
We need to copy the final DEVMODE details back in case any were invalid from the prefs and have been overridden by the printer.

Review commit: https://reviewboard.mozilla.org/r/50789/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/50789/

Comment 17

[Jim Mathies [:jimm]]

Comment on attachment 8749152 [details]
MozReview Request: Bug 1255336: Copy DEVMODE details back to print settings in GetDataFromPrinter. r?jimm

https://reviewboard.mozilla.org/r/50789/#review47827

Comment 19

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c98cab8c4344

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c98cab8c4344

Comment 22

[Bob Owen (:bobowen)]

Comment on attachment 8749152 [details]
MozReview Request: Bug 1255336: Copy DEVMODE details back to print settings in GetDataFromPrinter. r?jimm

Approval Request Comment
[Feature/regressing bug #]:
Regressed by bug 1238964.

[User impact if declined]:
Users will continue to run into problems with printing blank pages and printing resolution if using the pref print.always_print_silent=true.

[Describe test coverage new/current, TreeHerder]:
Tested manually.

[Risks and why]: 
Low - simple code change that only gets called when not printing normally.

[String/UUID change made/needed]:
None.

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 46+.  This is too late for 46, but I'm tracking there in case we end up with a 46.0.2 and it could potentially ride along.

Comment 24

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hello Bob, based on comment 6, if this is e10s only, we do not need to uplift this for Fx47 or Fx46 as they ship with e10s turned off by default. What do you think?

Comment 25

[Bob Owen (:bobowen)]

(In reply to Ritu Kothari (:ritu) from comment #24)
> Hello Bob, based on comment 6, if this is e10s only, we do not need to
> uplift this for Fx47 or Fx46 as they ship with e10s turned off by default.
> What do you think?

Hi, I thought this was e10s and content sandbox related (so only Nightly at the moment), but I was mistaken.
There is a separate bug that is, which I have filed as bug 1270447.

This problem, as originally reported, is on release (46).

Comment 26

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hello Gee, could you please verify this issue is fixed as expected on the latest Nightly build? Thanks!

Comment 27

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8749152 [details]
MozReview Request: Bug 1255336: Copy DEVMODE details back to print settings in GetDataFromPrinter. r?jimm

Recent regression in printing, Aurora48+, Beta47+

Comment 28

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6485fbf9000c

Comment 29

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/67b57ffeed5352ce93c403094185d9ccd4348cc4

Comment 31

[r.chrzanowski]

I have now realised it's not that resolution was ignored with always_print_silent=false but rather print.printer_name.resolution was reverted to the printer's default when user clicked OK in print dialog. 
Now it seems that resolution is reverted for both silent and non-silent printing in (tested on Nightly and FDE).

Comment 32

[Comorasu Cristian]

I tried reproducing this bug on Windows 10 x64 using Fx  46.0.1 build (20160502172042) and 47.0b6 build(20160516123243) by creating the print.always_print_silent pref (set to be true) and the pages were correctly printed.
Could you please confirm that this issue is indeed fixed using the Fx 47 beta 6 build?
https://archive.mozilla.org/pub/firefox/candidates/47.0b6-candidates/build1/win32/en-US/

Comment 33

[Bob Owen (:bobowen)]

(In reply to Comorasu Cristian from comment #32)

> Could you please confirm that this issue is indeed fixed using the Fx 47
> beta 6 build?

Yes, the fix made it into beta 4 build.

Comment 34

[TheRave]

I see the "print preview error window" still here if I try to print a frame and with silent print to true and e10s in today's Nightly.

This is the console output:
In Printing:Print:Done handler, got unexpected rv   2147500037.browser-content.js:509

Comment 35

[Bob Owen (:bobowen)]

(In reply to TheRave from comment #34)
> I see the "print preview error window" still here if I try to print a frame
> and with silent print to true and e10s in today's Nightly.
> 
> This is the console output:
> In Printing:Print:Done handler, got unexpected rv  
> 2147500037.browser-content.js:509

I suspect this is bug 1270447.

Comment 36

[Liz Henry (:lizzard) (relman/hg->git project)]

Wontfix for 46 at this point, as I don't think we will have a 46.0.2 now, and 47 should release in a couple of weeks, when this will be fixed.

Comment 37

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8749152 [details]
MozReview Request: Bug 1255336: Copy DEVMODE details back to print settings in GetDataFromPrinter. r?jimm

Clearing the m-r flag as 46 will EOL in a week and this fix is already in Beta47.

Comment 38

[Mark James]

We run Firefox as the touch-screen user interface for a machine, and have been using always_print_silent on Firefox 52esr to allow users to print reports with a single button. This started to fail silently or give the alert "An error occurred while printing" after we updated to Firefox 63. Turning off always_print_silent fixed it, but now operators have to do a two-step print.

I think browsers have to be written so they can always be configured to be used in controlled environments, not just on the untrusted web. We had a similar issue with starting in full screen being automatically reverted on every start. To get around it we had to start with a script that copied over xulstore.json. And don't get me started on the hoops we had to jump through to bypass security in the Java Plugin, still left with it continually expiring and stopping working, only bypassed now by re-writing it as a native-messaging extension.

Comment 39

[Bob Owen (:bobowen)]

(In reply to Mark James from comment #38)

We run Firefox as the touch-screen user interface for a machine, and have been using always_print_silent on Firefox 52esr to allow users to print reports with a single button. This started to fail silently or give the alert "An error occurred while printing" after we updated to Firefox 63. Turning off always_print_silent fixed it, but now operators have to do a two-step print.

I think browsers have to be written so they can always be configured to be used in controlled environments, not just on the untrusted web. We had a similar issue with starting in full screen being automatically reverted on every start. To get around it we had to start with a script that copied over xulstore.json. And don't get me started on the hoops we had to jump through to bypass security in the Java Plugin, still left with it continually expiring and stopping working, only bypassed now by re-writing it as a native-messaging extension.

Hi Mark - this bug was for a different issue with always_print_silent, which was resolved.

Would you file a new bug for this new problem please.
If you can find a regression range for it using https://mozilla.github.io/mozregression/ that would be great.

Comment 40

[Mark James]

Thanks Bob. I found my issue has been reported: Bug#1471854

Comment 41

[gee]

I don't have access to same environment as found in this bug report.