1034993 - Silent printing to file from addon pops-up a modal window asking for a filename

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[nub]

Somewhere in the javascript source code of the addon:

=========================================================
var printSettings = Components.classes["@mozilla.org/gfx/printsettings-service;1"]
	                    .getService(Ci.nsIPrintSettingsService).newPrintSettings;
printSettings.printerName = "Microsoft XPS Document Writer";
printSettings.printToFile = true; 
printSettings.showPrintProgress = false;
printSettings.toFileName = outputFileName; // Name of output file
printSettings.printSilent = true; // Don't show the printing popup

browserPrint.print(printSettings, null);
======================================================

The last line should trigger a print to the file "outputFileName" silently since "printSettings.printSilent = true;" has been specified. However, a modal window instead pops up asking for a filename the document should be printed to. (Note that the modal window for the printer settings is not shown, as expected.)

Note that the bug is there in Firefox 24.1.1 esr and in Firefox 24.6.0 esr but is not present in Firefox 30.0.0.

Also note that the bug appears unrelated to the "Microsoft XPS Printer" as attempting the same with another PDF printer leads to the same problem.

Comment 1

[:Gijs (he/him)]

(In reply to nub from comment #0)
> Note that the bug is there in Firefox 24.1.1 esr and in Firefox 24.6.0 esr
> but is not present in Firefox 30.0.0.

I don't think this is important enough a bug to be backported to ESR 24. If you want to make a serious case for that to happen, I expect that at a minimum you would need to find out how this got fixed (and even if you did, that would not guarantee that we could or would uplift that fix to ESR 24, which is EOL'd in 2 releases' time, as ESR 31 is the next ESR release will be released Real Soon Now). mozregression ( http://mozilla.github.io/mozregression/ ) might help you with this, should you choose to pursue it (I tried to search bugzilla for a bug that matches this fix but couldn't find one quickly).

Comment 2

[nub]

Gijs, thank you for your comment. I did try the dichotomy and the result is:
Last good revision: 73eefb421e2a (2014-01-30)
First bad revision: 7e79536aca0a (2014-01-29)

From the set of revisions left, my guess is 2a8f945b28da, so that the bug you attempted to find is most likely Bug 701479 and the fix probably lies in the removal of (and corresponding cleaning of the functions depending on CheckForPrintToFile):

   1.212 -        if (!aIsPrintPreview) {
   1.213 -          rv = CheckForPrintToFile(mPrintSettings, deviceName, nullptr);
   1.214 -          if (NS_FAILED(rv)) {
   1.215 -            free(deviceName);
   1.216 -            free(driverName);
   1.217 -            return NS_ERROR_FAILURE;
   1.218 -          }
   1.219 -        }

It would be great to have this backported to the currently supported ESR...

Comment 3

[:Gijs (he/him)]

Jim, do you think the patch from bug 701479 is ESR-backportable?

Comment 4

[Jim Mathies [:jimm]]

(In reply to :Gijs Kruitbosch from comment #3)
> Jim, do you think the patch from bug 701479 is ESR-backportable?

We haven't had any regressions filed against that bug and I'm sure it'll apply so.. sgtm.

Comment 5

[:Gijs (he/him)]

Attachment: Remove usage of EnumPrintersW to test if port is FILE:. nsDeviceContextSpecWin shouldn't start UI for asking for a filename nor query all possible printers. a=?

Comment 6

[:Gijs (he/him)]

Comment on attachment 8453016 [details] [diff] [review]
Remove usage of EnumPrintersW to test if port is FILE:. nsDeviceContextSpecWin shouldn't start UI for asking for a filename nor query all possible printers.  a=?

Carrying over review.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: ignoring 'printSilent' flag makes it impossible to print to file without user interaction; this is otherwise a low risk patch, so the potential for harm in taking it seems limited.
User impact if declined: extraneous prompt when printing to file
Fix Landed on Version: 29
Risk to taking this patch (and alternatives if risky): low risk, baked 2 releases with no known regressions filed
String or UUID changes made by this patch: none

NB: I'm asking on behalf of the reporter. nub, if you have anything to add to the above, that might be useful in terms of establishing the need/justification for this to land on the 24 branch (which is generally "very stable", so we don't take fixes lightly), that is probably helpful.

Comment 7

[nub]

I believe you aptly summarised the whole story.

I can add that this used to work under Windows XP (24esr) but does not in Windows 7 anymore.

Also, I attempted to define the port of the printer to be "FILE:" as a workaround the problem with the 24esr releases. It seems to work for some locations of the filename (such as the Desktop where I managed to get rid of the dialog box) but not for others like the Roaming folders which triggers a strange behaviour from Windows 7 (see the attached screenshot) -- another bug?

Comment 8

[nub]

Attachment: Print To File Dialog Box & Error message

Comment 9

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/releases/mozilla-esr24/rev/810977d38c0d


AFAICT this missed the build 1 deadline which was apparently yesterday (!?). I don't know if there'll be another 24 build before the release next week. :-\

Lukas?

Comment 10

[:Gijs (he/him)]

Backed out for jetpack failures:

remote:   https://hg.mozilla.org/releases/mozilla-esr24/rev/31b0c1ff3c0b

like:

TEST-UNEXPECTED-FAIL | content-permissions/main.testCrossDomainIframe | Timed out
TEST-UNEXPECTED-FAIL | content-permissions/main.testCrossDomainXHR | Timed out 

https://tbpl.mozilla.org/php/getParsedLog.php?id=43823237&tree=Mozilla-Esr24&full=1


No idea why those tests are failing after this patch.

Comment 11

[:Gijs (he/him)]

I don't think I can justify spending the time to investigate fixing this further.

Comment 12

[nub]

Gijs, thank you for your consideration and your time to make these attempts. This is very much appreciated.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Good times, turns out this patch wasn't at fault for those failures. Re-landed for the 24.8 release.

https://hg.mozilla.org/releases/mozilla-esr24/rev/f926a1b62f2c