1668193 - print blank page , when enable the silent print in firefox 81

Status: RESOLVED WORKSFORME

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

Description

[arunkumar1311195]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

os:windows 10.0.18363, firefox:81
1.go about:config
2.set print.always_silent_print = true, print.save_print_settings=false, remove print_printer
3.print

Actual results:

It prints empty page.
it works fine till firefox 80.

Expected results:

it prints the page with content.

Comment 1

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: print_silent.gif

I can reproduce the issue on Windows 7x64 with Firefox 81.0.1 (20200930150533) by following the STR:

1. Open Firefox with a clean profile and set print.always_print_silent:true.
2. Open a random webpage and hit Ctrl+P (please see the attached screen recording).

Also Firefox 82.0b5 and Firefox Nightly 83.0a1 (20200930214529) are affected.
I cannot reproduce the issue with Firefox 80.0.1 (20200831163820).

Comment 2

[Alice0775 White]

Regression window:

The "silent print" does not work. Ctrl+P shows print preview.
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b009f7677bc0d0f86b6ff8ec6c7de62dd160760f&tochange=01120cb14f26f1c4b43ccd4e99fae6e81774e5f7

Ctrl+P prints blank page.
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b6d1532f6cd4f3dabe20557fddcfb8595a6ba809&tochange=bec106588c1745976dbf422de0849456ec92edde

Comment 3

[Cristian Fogel [:cfogel]]

Updating flags, thanks for the help Alice!

Comment 4

[Sam Foster [:sfoster] (he/him)]

Looks like this needs triage, forwarding to jwatt in case its not already on his radar.

Comment 5

[Andrei Purice]

Hey arun,
Can you still reproduce this issue or should we close it?

Comment 6

[arunkumar1311195]

(In reply to Andrei Purice from comment #5)

Hey arun,
Can you still reproduce this issue or should we close it?

hey andrei purice, I had checked until firefox version 89, bug not fixed, i can reproduce it

Comment 7

[Pete Collins (MDG)]

This is a legit bug.

I can reproduce on ff91esr.

Steps to reproduce:

1. remove user profile
2. launch ff
3. set pref print.always_print_silent to true
4. go to test page: https://www.mozdevgroup.com/dropbox/test/print.html
5. click on print button
6. result a blank page will always be printed

This is a result of the printsettings never being initialized. Since printPageSetup.xhtml which loads printPageSetup.js initializes the printsettings when the page loads, if silent printing is enabled before this page is ever loaded, the printsettings never get initialized which results in a blank page being printed until the user loads this print dialog page after which it is no longer an issue.

Comment 8

[Daniel Holbert [:dholbert]]

Is this still reproducible in Firefox Nightly? (Note, I'm assuming step 1 in comment 7 "remove user profile" just means "test with a brand-new Firefox profile")

I think it might be fixed; if I use the STR from comment 7 (including a fresh Firefox profile), here's what I see:

• Firefox ESR 91.6.0esr doesn't print anything (not even a blank page, for me); instead I see this in my Ctrl-Shift-J Browser Console: Uncaught (in promise) undefined

• Firefox Nightly 99.0a1 (2022-02-08) (64-bit) prints the page as-expected, and there's no such error in my browser console.

Comment 9

[Daniel Holbert [:dholbert]]

Note that there were some code-changes that involved silent printing over the last few months; in particular, bug 1669149 introduced a new problem (more recent than this bug here) which was described in & fixed in bug 1741698.

So: it's conceivable that this was fixed by that work (given my observations in comment 8 which seem like this being fixed -- though I'm not sure if I was hitting exactly this in old builds vs. hitting something else, since I didn't quite get "blank page" result -- I just got nothing printed at all.)

Pete, would you mind testing Nightly ( https://nightly.mozilla.org/ ) on your end with your steps from comment 7, and seeing if this looks fixed for you?

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase from comment 7

Comment 11

[Daniel Holbert [:dholbert]]

Still waiting to hear back on comment 9; but for now based on my testing in comment 8, it looks like this is WORKSFORME.

Please reopen if folks are still seeing this, though - thanks!