1667509 - Tab-modal printing "Save to PDF" option doesn't work (produces zero-sized file, and prints to regular printer)(jemalloc freed memory?)

Status: RESOLVED FIXED

(Core :: Printing: Setup, defect, P1)

Description

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

When I:

• Click on the Print icon in Gmail
• Use the Gmail print preview dialog (not the "system dialog") and choose destination "Save to PDF"
• Click "Save" and select a destination folder

Instead of writing a PDF, the document is printed to my system default printer and a zero-byte file is written to the destination folder.

Using the system dialog works as expected.

I wasn't sure whether to file this as a printing bug or webcompat! I'm using Dev Edition 82.0b3 on MacOS 10.15.6.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Tim Smith 👨‍🔬 [:tdsmith] from comment #0)

When I:

• Click on the Print icon in Gmail
• Use the Gmail print preview dialog (not the "system dialog") and choose destination "Save to PDF"

Note/correction: it seems Gmail pops open a new window, and then calls window.print() on that Window, which triggers Firefox's new integrated print-preview dialog (which is indeed distinct from the system dialog).

Using the system dialog works as expected.

(This is the "Print using the system dialog" link at the bottom of the dialog, right?)

Two requests:
(1) Would you mind seeing if you hit the same issue when doing Cmd+P on https://example.org/ ? (That should trigger the same print UI with "Save To PDF" as an option.)
(2) Would you mind testing Nightly ( https://nightly.mozilla.org/ ) and seeing if you hit the same issue there (with Gmail)?

Comment 2

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

Oh! Yes, same UI and same issue on example.com.

It doesn't reproduce with a new profile on dev edition, or in current Nightly.

The issue appears again with my regular profile in dev edition after restarting the browser.

Comment 3

[Daniel Holbert [:dholbert]]

FWIW, this sounds slightly related to the issue that was originally described in bug 1660794, though it's not exactly the same.

It's interesting / good to know that a fresh profile isn't affected. Could you post your about:support data? I think the print.* preferences (listed there) are particularly interesting & might be involved here.

(visit about:support, hit "copy text to clipboard"; then, click "attach new file" on this bug page here, and paste your clipboard into the "File:" textarea at the top.)

Comment 4

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

Attachment: about:support

Comment 5

[Jonathan Watt [:jwatt]]

I've managed to reproduce the issue where the "Save to PDF" printer prints to my default physical printer. If the "global" pref print.print_to_file is set to false, then when I first print to the "Save to PDF" printer its nsIPrintSettings object picks up that value and causes the print to go to the wrong place. Worse still, I then end up with the pref print.printer_Mozilla_Save_to_PDF.print_to_file also set to false after that first print to the "Save to PDF" printer. That means that if I remove the "global" pref print.print_to_file I still have the misbehavior. I have to remove both print.print_to_file and print.printer_Mozilla_Save_to_PDF.print_to_file to fix things.

Comment 6

[Jonathan Watt [:jwatt]]

Tim, can you copy all your printing prefs and attach them to this bug? (about:support -> open profile folder/profile directory -> get prefs from prefs.js)

Comment 7

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

Attachment: Printing prefs

Attached!

Comment 8

[Jonathan Watt [:jwatt]]

Thanks!

Are you sharing this profile between a mac and a linux/windows machine? It's curious that you have print settings saved to both the global pref names (those without a printer name in the pref name) and to printer specific pref names. The fact that you have the global print.print_duplex pref set in particular seems to suggest you have used this profile on linux fairly recently, but you've reported this against mac.

Presumably the -437918235 value that you have in those prefs is what's causing the problem here. (The print_paper_* pref values look fine.) Can you test whether resetting those values to zero (start with the print_resolution prefs, but also for print_duplex) fixes things for you?

Comment 9

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

No, I've never used this profile except on this Macbook, but it's a couple years old.

Clearing the print_resolution and then the print_duplex prefs had no effect. I could still reproduce after restarting the browser.

Comment 10

[Jonathan Watt [:jwatt]]

(In reply to Tim Smith 👨‍🔬 [:tdsmith] from comment #9)

No, I've never used this profile except on this Macbook, but it's a couple years old.

Huh, interesting. That strongly suggests that we at some point must have had code that was saving print settings to unprefixed prefs. :-/ I've filed bug 1668210 and put up a patch there to prevent that happening again.

Clearing the print_resolution and then the print_duplex prefs had no effect. I could still reproduce after restarting the browser.

Sorry, I was getting ahead of myself. We need to wait for the part 1 patch from bug 1667953 to make it into Nightly first.

Comment 11

[Blake Winton (:bwinton) (:☕️)]

(Based on the severity descriptions, I think this is an S2, but marking it as P1 because it could be really important.)

Comment 12

[Jonathan Watt [:jwatt]]

Tim, Nightly 2020-10-01 should have the fix for bug 1667953 now. Can you update and retest, and then retest again after resetting the prefs with the -437918235 values to zero (start with the print_resolution prefs, but also try resetting print_duplex if that doesn't help).

Comment 13

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

I'm using my affected profile with Dev Edition so I think I need to wait for 82.0b6 to ship; I'll hold the ni? until then.

Comment 14

[Jonathan Watt [:jwatt]]

An alternative would be to copy the prefs.js file from the Dev Edition profile to a Nightly profile. (Confirming first that the bug is still present in an older Nightly from, say, the 28th, then updating that build to the 1st October build and checking that the issue is fixed.)

A bit of a pain, I know, but given the time pressure on this printing work it would be much appreciated if you have the time and can do that.

Comment 15

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

b6 came out before I had a chance to test :) I could no longer reproduce after upgrading to b6. The invalid print_resolution and print_duplex prefs were gone when I went to check them.

Comment 16

[Jonathan Watt [:jwatt]]

Okay, thanks. Let's call this fixed by bug 1667953 then. I'm still a bit worried about these -437918235 values since that indicates memory jemalloc freed, and print_duplex hasn't been around that long (since bug 1659856). I'm not sure what else we can do to figure out how those values got into your prefs though. I didn't manage to find anything that looked wrong with the code, or that misbehaved for me. I guess we'll just have to hope that was due to some bug that we since fixed, and keep a look out for other instances of that in future... :-(