Save to PDF actually prints on macOS (stop propagating unprefixed print.print_to_file=false)
Categories
(Core :: Printing: Output, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox81 | --- | unaffected |
firefox82 | blocking | verified |
firefox83 | + | verified |
People
(Reporter: emir1998, Assigned: jwatt)
References
(Regressed 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [print2020_v82][old-ui-])
Attachments
(2 files, 1 obsolete file)
(deleted),
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details |
(deleted),
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0
Steps to reproduce:
- Open any page
- Do File->Print
- Chose "Save to PDF" as the printer and save
Actual results:
An empty file with the chosen name is created and the print job is queued on the default printer.
Expected results:
A PDF file with the contents of the page should be created, no real print job should be queued.
Updated•4 years ago
|
Comment 1•4 years ago
|
||
[Tracking Requested - why for this release]: Regression maybe caused by the print preview modernization work targeting 82
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 2•4 years ago
|
||
I'm able to reproduce this (tried printing this bug page as an example).
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
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.
Assignee | ||
Comment 4•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
The part 1 patch will stop this happening to anyone using Nightly/Beta who hasn't already been bitten by this yet. But it won't fix up their prefs for those users that have been. The reason for that is because the frontend code calls initPrintSettingsFromPrefs
after it sets printToFile = true
:
We don't have nearly enough Beta users as it is, so I think we should really try to fix this up for the users we do have.
Assignee | ||
Comment 7•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 9•4 years ago
|
||
bugherder |
Assignee | ||
Comment 10•4 years ago
|
||
Comment on attachment 9178563 [details]
Bug 1667953 p1. Stop reading printer specific settings from global prefs. r=bobowen
Beta/Release Uplift Approval Request
- User impact if declined: Some users may have 'Save as PDF' in the new UI send a print job to a physical printer instead.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This should only affect users with corrupt prefs.
- String changes made/needed:
Assignee | ||
Updated•4 years ago
|
Comment 11•4 years ago
|
||
bugherder |
Comment 12•4 years ago
|
||
Comment on attachment 9178563 [details]
Bug 1667953 p1. Stop reading printer specific settings from global prefs. r=bobowen
approved for 82.0b6
Updated•4 years ago
|
Comment 13•4 years ago
|
||
bugherder uplift |
Comment 14•4 years ago
|
||
Verified with 83.0a1 (2020-10-01) and 82.0b6 on macOS 11.0
Assignee | ||
Comment 15•4 years ago
|
||
I used mozregression to track down when we started propagating print.print_to_file
onto the print.printer_Mozilla_Save_to_PDF.print_to_file
when it's not yet set:
So this was caused by bug 1663669.
Updated•4 years ago
|
Assignee | ||
Comment 16•4 years ago
|
||
In the Phabricator revision for the first patch I made the following comment for the change to nsPrintSettingsService::InitPrintSettingsFromPrefs
which makes InitPrintSettingsFromPrefs
no longer read certain unprefixed prefs:
This list is made to match the prefs we currently set in all.js, minus
the unwritable margins which don't seem safe to even include. So
this list specifically excludes:
kInitSaveUnwriteableMargins
kInitSaveOddEvenPages
kInitSaveBGColors
kInitSaveBGImages
kInitSavePaperSize
kInitSaveResolution
kInitSaveDuplex
kInitSaveOrientation
kInitSavePrinterName
kInitSavePrintToFile
kInitSaveToFileName
kInitSavePageDelay
kInitSaveMargins
kInitSaveNativeData
kInitSaveShrinkToFit
kInitSaveScaling
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 17•4 years ago
|
||
These were lost in bug 1667953, but I don't think print_bgimages /
print_bgcolor should be printer-specific only.
Comment 18•4 years ago
|
||
Comment on attachment 9203699 [details]
Bug 1667953 - Restore read from global print settings for a few settings, including print_bgcolor and print_bgimages. r=jwatt
Revision D105465 was moved to bug 1692845. Setting attachment 9203699 [details] to obsolete.
Description
•