Print settings are not saved from print job to print job in Thunderbird
Categories
(MailNews Core :: Printing, defect)
Tracking
(thunderbird_esr68 affected)
| Tracking | Status | |
|---|---|---|
| thunderbird_esr68 | --- | affected |
People
(Reporter: nathanael.naeri, Unassigned)
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0
Steps to reproduce:
- Select File > Print to print an e-mail.
- Choose Print to File. Print to File is the only printer available on my system, so I am not sure if actual printers are affected.
- Change a few print settings from their current values. I have tried File name, Scale, Ignore Scaling and Shrink to Fit Page Width, Print Backgrounds, Header and Footer. The other settings may be similarly affected.
- Print.
- Run steps 1-2 again.
Actual results:
The print settings have reverted to their previous values, i.e. Thunderbird hasn't saved the user's modifications.
Tested with add-ons disabled in Safe Mode.
Expected results:
I expected Thunderbird to save the user's modifications from print job to print job. As far as I can tell, this is what Firefox does.
I have found old reports of similar bugs in Firefox (bug 1136855, bug 526811, bug 539427), but nothing in Thunderbird.
Using Thunderbird 68.7.0 on Ubuntu 20.04. Interestingly, my current print settings are not the stock "~/mozilla.pdf, 100% scale, print headers and footers" settings. They're customized already, which means that a previous version of Thunderbird used to correctly save print settings from print job to print job. I have been using Ubuntu 20.04 since Dec 2019. Back then in was Thunderbird 68.3.0 according to the APT package's changelog.
|
||
Comment 1•4 years ago
|
||
I can confirm this using the Thunderbird 68.7.0 from Ubuntu.
I also installed 68.3.0 into my test user account, created a test profile and can reproduce.
Firefox does retain the changed settings, but that is version 76.
Appears that this works properly in my 77.0b1 and 78.0a1.
|
||
Comment 2•4 years ago
|
||
Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
||
Comment 3•4 years ago
|
||
Unfortunately, I don't think we'll be fixing this for 68 when it works on 77/78. We wouldn't be able to get proper feedback to land it on 68.
Description
•