print.always_print_silent doesn't print certain PDFs on Ubuntu - Ok on Windows
Categories
(Core :: Printing: Output, defect, P3)
Tracking
()
People
(Reporter: ecollart, Unassigned)
References
(Depends on 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Steps to reproduce:
1- set print.always_print_silent in about:config
2- be sure to have a default printer defined
3- open a PDF file in Firefox
4- click on "Print" icon
=> nothing happen !
We are obliged to use a Windows PC because there it works fine !!!!!
The system is used to register user to a dog training in dog club; user just present a badge to a bar code scanner, click to confirm what training to select and a ticket is automatically printed. We never succeeded to do that using Ubuntu since years !
Actual results:
Nothing
Expected results:
Should print to default printer without any popup
Reporter | ||
Comment 1•4 years ago
|
||
Doing the same using a text file works fine !
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 3•4 years ago
|
||
Sorry to hear about this issue, & thanks for the report! I tried to reproduce -- I'm using Ubuntu locally -- but I wasn't able to reproduce. (I'm using Firefox 84.0.2.)
A few questions / requests:
(1) Just to be sure that I & others are matching your steps as closely as possible, we should be testing with a the same PDF file. Could you try this one and see if it triggers the issue (it doesn't have any trouble for me):
https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf
(2) Firefox 85 was released this week, though I'm not sure if the Ubuntu repositories have it yet. Once you've received that update, would you mind testing that version and seeing if it's still affected?
Reporter | ||
Comment 4•4 years ago
|
||
Hello,
your dummy.pdf prints effectively fine on Ubuntu 20.04.latest and Firefox 84.
I learned that the PDF we are trying contains instructions for the printer (that is a Brother Label printer QL-700). I requested an example and will post it here upon reception and confirm if it works or not on my test PC.
Note that we tried on a RaspBerry 4 with RaspBerry Pi OS and Firefox ESR version 78 and it works fine !
Eric Collart
Comment 5•4 years ago
|
||
Thanks!
Updated•4 years ago
|
Reporter | ||
Comment 6•4 years ago
|
||
Hello,
I don't understand what changed since I did the test because today it works on a latptop running Ubuntu 20.04 and Firefox 84.0.2 (64 bits) for both your PDF file and our generated one (https://u.pcloud.link/publink/show?code=XZfmgbXZWkAq7BdF6hJNCk2lXTbPfzQA2FK7). I must say that this laptop got updates since I tested.
I tested without using step 1 and step 2. It was working also on the VirtualBox VM ( same versions).
Being confused I can't reproduce that problem anymore, I restarted from scratch on the VM and followed again exactly the same steps described (note that I define default printer in step 2, not before) and no PDF file is printed and nothing listed in the print queue !
Same procedure done on the laptop and no problem there ! Completely confused now !
To define a printer as default (point 2), I open the Settings - Printers - Additional Printer Setting and I right-click on the printer I want as default.
I also tried to change default printer (I have 2 printers available) and problem is same even after a reboot ! (BTW, kernel was updated during one of the reboot I did although I ask to delete update to a later date...)...
So the problem is still exhibiting sometimes but I don't know why nor how !
Sorry but now I am lost, I hope you can find useful info in what I describe !
Eric Collart
Reporter | ||
Comment 7•4 years ago
|
||
A friend just test on Linux Mint 18.3 with Firefox 84.0.2 (64 bits) running in VirtualBox 6.1 and impossible to print our generated PDF !!!!
Looks like a weird problem !
Opening the same PDF file in the PDF viewer, it can be printed with no problem.
Eric
Reporter | ||
Comment 8•4 years ago
|
||
Testing further, we find that changing default printer (in printers parameters) doesn't seem to be taken in account by Firefox even after closing and restarting Firefox. I think it works after a reboot but I need to re-test to be sure.
My friend found print_printer parameter in about config was still pointing on a previous default printer no more connected. This was the QL-700.
He deleted the print_printer parameter and Firefox now magically prints correctly to the actual default printer !
I think we figured out where is the problem ! Default printer management within Firefox !
The fact that we saw nothing in print queue of the QL-700 is caused by the Brother provided driver shows a QL-700 ready being connected or not ! Thats ' a bug to report to Brother; nothing to do with Firefox.
Let me know if you have enough info to reproduce the problem or you need more from us !
Eric Collart and Daniel Dassonville
Comment 9•4 years ago
•
|
||
Thanks! So let me post my understanding of the problem here, and let me know if I'm missing anything:
(1) Firefox starts out using the system-default printer (I think) and then from that point on, we just save the user's most recent printer-choice.
(2) If you set print.always_print_silent
, then the user is effectively locked on to that saved printer (as long as the OS still offers it, at least); there's no UI for choosing another.
(3) In your case, the saved printer was disconnected, and you had probably chosen a different system-default printer, which Firefox was not picking up because it was still trying to use the most recent one.
(4) Normally, a user in this situation might still see an OS error for Firefox pushing print-jobs to a disconnected printer; but in your case, that wasn't happening due to a print driver bug.
Does that sum it up? Am I missing anything?
I don't know that the print.always_print_silent
workflow is especially well-supported (obviously there's no UI that pops up to configure it, by-design); but it's still valuable to track pain points around it with bugs like this one. I'm not sure what we could do better here, outside of adding some UI to make this "silent" operation less-silent. It's possible that users would be better-served if we just always used the system-default printer for print.always_print_silent
... but on the other hand, there could very well be users out there who have workflows set up that depend on this operation printing to a particular non-default printer, so I'd be hesitant to make that change.
Reporter | ||
Comment 10•4 years ago
|
||
Hello,
the summary is correct and I agree on point 4, it's a printer driver bug.
I do not understand why Firefox doesn't update its parameters when the user expressly change the default printer. I don't see why this must be locked because of print.always_print_silent is set. For me the only goal of this setting is to suppress the confirmation popup, no ?
Now that we know how to workaround that (delete print_printer parameter), it's OK if you decide not to implement a fix/change but it would probably be cleaner if the user could trigger the default printer change somewhere easier than in about:config ...
The feature is used in two self-made "kiosk" in a dog club where members present a membership barcode to register to a session for his dog and the program sends an on-the-fly generated PDF file to be print with no user interaction as a registration proof to give to the teacher of the dog session. Those "kiosk" allow an easy flow of the 350 members of the club; before they had to queue at reception to manually do the job.
Having Firefox refreshing its default printer settings if default printer setting is expressly changed in Ubuntu printer settings would ease label printer replacement in case of trouble and will also ease dog club's program development testings (actually testing to replace Windows based PC by RaspBerry based PC for the "kiosk").
Thanks anyway for the time you spent to help us and I hope it will be beneficial for other Firefox users too !
Eric Collart
Daniel Dassonville
Comment 11•4 years ago
|
||
(In reply to Eric Collart from comment #10)
I do not understand why Firefox doesn't update its parameters when the user expressly change the default printer.
It's pretty simple -- Firefox just assumes that you're likely to want to print to the same printer that you printed to last time (whether or not that's your system default).
Simple example of where this is helpful, with a regular firefox installation (not a kiosk): suppose your system default is a Brother printer (for office-type applications); but when you're in Firefox, you're usually printing 1000-page eBooks to a PDF "virtual printer". Firefox will remember the PDF "virtual printer" when you choose it the first time, and it will offer that by default in the select-printer dropdown from that point on (until/unless you choose something different in the print dialog), so you don't accidentally send a 1000-page document to your physical Brother printer. Firefox will continue to do this (remembering your last-chosen printer), even if your system default print target changes; this makes sense and is helpful, because in this hypothetical scenario, the user's not even using the default print target in Firefox anyway.
Anyway, that's the reasoning behind Firefox's current behavior. However. In your actual scenario in this bug, you were using the system default print target (and you'd never made a manual choice to tell Firefox to use anything besides the system-default); so it's quite rational for you to expect that Firefox will continue to use the system default, even if that system default changes. So I can understand how the print_printer
last-printer-saving behavior is unexpected for you.
I filed bug 1690208 with a proposal for how we might address this, which would hopefully prevent issues like this from happening in the future.
Reporter | ||
Comment 12•4 years ago
|
||
Hello,
Thank you very much, Daniel !
I subscribed to the new created bug to keep an eye on that ...
Stay safe
Eric Collart
Updated•4 years ago
|
Description
•