print.save_print_settings=false doesn't work
Categories
(Core :: Printing: Setup, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox108 | --- | fixed |
People
(Reporter: vesfatica, Assigned: jwatt)
Details
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1755153 p2 - Prevent saving print settings to prefs if print.save_print_settings=false. r=emilio
48 bytes,
text/x-phabricator-request
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0
Steps to reproduce:
Firefox v97.0
I have print_printer = HP LaserJet 1020
and
print.save_print_settings = false
Use the default printer (as above) then use a different printer (Microsoft Document Writer)
Actual results:
THe next time I print, Microsoft Document Writer is the default.
Expected results:
The default should have stayed HP LaserJet 1020
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Printing: Setup' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
I don't know what the Bugbug's comment means. My printers have not changed in a few years. The behavior I described started after a recent update to v97.0 and also coincided with a new print dialog.
Comment 3•3 years ago
|
||
Yeah, the bot just moved the bug to the right component. The new print-settings dialog doesn't check the pref it seems. Jonathan, perhaps we should move the check for that pref into SavePrintSettingsToPrefs
? Seems less error prone than having to check it on all callers.
![]() |
Assignee | |
Comment 4•3 years ago
|
||
Yeah, we should do something like that, but we'd also need an override bit we could pass since some of the dialogs save directly to settings by design. I'll take a look.
Comment 5•3 years ago
|
||
The severity field is not set for this bug.
:hiro, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 7•3 years ago
|
||
The severity field is not set for this bug.
:hiro, could you have a look please?
For more information, please visit auto_nag documentation.
It has been a couple months and 4 or 5 updates!
Will this be fixed?
![]() |
Assignee | |
Comment 10•3 years ago
|
||
![]() |
Assignee | |
Comment 11•3 years ago
|
||
Depends on D146943
![]() |
Assignee | |
Updated•3 years ago
|
Comment 12•3 years ago
|
||
There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:jwatt, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Reporter | ||
Comment 13•3 years ago
|
||
Is there an estimate of when this will be fixed? Thanks!
![]() |
Assignee | |
Comment 14•3 years ago
|
||
I'd prefer to land this with a test, but if I don't get that done before the end of the week then I'll land without it. That'd mean shipping in Firefox 106.
Reporter | ||
Comment 15•2 years ago
|
||
It's not fixed in 106.0.1.
Comment 16•2 years ago
|
||
Comment 17•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/fec233866f98
https://hg.mozilla.org/mozilla-central/rev/895b457e29f8
Reporter | ||
Comment 18•2 years ago
|
||
It's apparently fixed. I tested in two ways, from the print icon on the main window toolbar and from the print icon in the PDF-view toolbar. The last printer is not remembered, as desired. Thanks for hanging in there!
Description
•