FF91/Linux -- Printing to cups &/or socket:// printers consistently FAILs silently; all other apps OK
Categories
(Core :: Printing: Output, defect)
Tracking
()
People
(Reporter: pgnet.dev, Unassigned, NeedInfo)
References
Details
I run FF 91.0/release, from upstream, on Linux (Fedora34), with KDE DE.
Name Firefox
Version 91.0
Build ID 20210804193234
Distribution ID
Update Channel release
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
OS Linux 5.13.8-200.fc34.x86_64 #1 SMP Wed Aug 4 19:59:54 UTC 2021
CUPSd runs on the machine
ps ax | grep cups
16440 ? Ss 0:00 /usr/sbin/cupsd -l
16442 ? S 0:00 /usr/lib/cups/notifier/dbus dbus://
rpm -qa | grep -i cups | sort
cups-2.3.3op2-7.fc34.x86_64
cups-client-2.3.3op2-7.fc34.x86_64
cups-filesystem-2.3.3op2-7.fc34.noarch
cups-filters-1.28.9-2.fc34.x86_64
cups-filters-libs-1.28.9-2.fc34.x86_64
cups-libs-2.3.3op2-7.fc34.x86_64
python3-cups-2.0.1-10.fc34.x86_64
An HP LaserJet is attached over Ethernet, via socket:// protocol.
Printing works flawlessly everywhere -- from all KDE & non-KDE apps, including all Chrome-based browsers, as well as Thunderbird 78*.
Except from Firefox.
Any/all attempts to print simply never connect to the printer, at all.
No errors dialogs.
No relevant output in cups or systemd/journal logs.
Print to PDF does work; I can then open the PDF in Okular, and print from there.
Problem is fully reproducible with
SafeMode @ desktop
vanilla profile @ desktop
clean install @ desktop
as well as
clean install @ clean linux VM
I.e., still no print.
In the clean/safemode/vanilla installs, BrowserConsole shows, on 'Print' of any single page,
TypeError: browser is nullBrowserElementParent.jsm:24:21
receiveMessage resource://gre/actors/BrowserElementParent.jsm:24
where
/* vim: set ts=2 sw=2 sts=2 et tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
"use strict";
var EXPORTED_SYMBOLS = ["BrowserElementParent"];
/**
* The BrowserElementParent is for performing actions on one or more subframes of
* a <xul:browser> from the browser element binding.
*/
class BrowserElementParent extends JSWindowActorParent {
receiveMessage(message) {
switch (message.name) {
case "DOMWindowClose": {
// This message is sent whenever window.close() is called within a window
// that had originally been opened via window.open. Double-check that this is
// coming from a top-level frame, and then dispatch the DOMWindowClose event
// on the browser so that the front-end code can do the right thing with the
// request to close.
if (!this.manager.browsingContext.parent) {
let browser = this.manager.browsingContext.embedderElement;
24 let win = browser.ownerGlobal;
// If this is a non-remote browser, the DOMWindowClose event will bubble
// up naturally, and doesn't need to be re-dispatched.
if (browser.isRemoteBrowser) {
browser.dispatchEvent(
new win.CustomEvent("DOMWindowClose", {
bubbles: true,
})
);
}
}
break;
}
}
}
}
|
||
Comment 1•5 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•5 years ago
|
||
I couldn't repro this, and the exception seems harmless / a red herring.
Is there any chance you could run pip install --user mozregression on a terminal, then MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 78 --bad 91 to find what broke this on your setup? Thanks!
Verified that print was failing with my usual desktop FF instance. It was.
Installed mozregression, and exec'd the bisect, from within ~/TMP.
Found no 'bad' instances in the 78-91 range.
?!
Immediately after, re-launched my usual desktop FF instance -- and, suddenly, able to print reliably from within FF.
This feels like cache ... but I'm not clear what/where a bisect procedure would overwrite :-/
Would the mozregression sequence have possibly overwritten/cleared any cache(s) that'd be shared with the normal instance?
|
|
||
Comment 4•5 years ago
|
||
Huh, that's very bizarre! I can't think of anything that should be shared with the mozregression instance.
Currently, printing from FF using 'new UI' is working.
BUT, the "Use system dialog" option is not ...
I understand the UI's/dialogs for the two are different ... are the Print mechanisms different?
E.g., direct via socket:// vs cups?
revisiting, this problem has reappeared on yet another new-install
atm, on linux/KDE + cups, printing
(1) @ thunderbird 91.0.1 OK
(2) @ firefox 91.0.1 / SafeMode FAILS
(3) @ brave 1.28.106 OK
(4) @ kate 21.08.0 OK
(5) @ "everything else ..." OK
this is running
lsb_release -rd
Description: Fedora release 34 (Thirty Four)
Release: 34
uname -a
Linux desk 5.13.12-200.fc34.x86_64 #1 SMP Wed Aug 18 13:27:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
with cups,
rpm -qa | grep -i cups | sort
cups-2.3.3op2-7.fc34.x86_64
cups-client-2.3.3op2-7.fc34.x86_64
cups-filesystem-2.3.3op2-7.fc34.noarch
cups-filters-1.28.9-2.fc34.x86_64
cups-filters-libs-1.28.9-2.fc34.x86_64
cups-ipptool-2.3.3op2-7.fc34.x86_64
cups-libs-2.3.3op2-7.fc34.x86_64
cups-printerapp-2.3.3op2-7.fc34.x86_64
gutenprint-cups-5.3.4-4.fc34.x86_64
python3-cups-2.0.1-10.fc34.x86_64
details,
(1)
@ thunderbird 91.0.1
exec:
File --> "Print ..."
page prints OK
journalctl -f | grep -i cups
Aug 22 20:34:32 desk cupsd[8733]: [Job ???] Request file type is application/pdf.
Aug 22 20:34:32 desk cupsd[8733]: [Job 1401] Adding start banner page "none".
Aug 22 20:34:32 desk cupsd[8733]: [Job 1401] Adding end banner page "none".
Aug 22 20:34:32 desk cupsd[8733]: [Job 1401] File of type application/pdf queued by "pgtest".
Aug 22 20:34:32 desk cupsd[8733]: [Job 1401] Queued on "hp4050_pcl3_hpijs" by "pgtest".
Aug 22 20:34:32 desk cupsd[8733]: [Job 1401] Started filter /usr/lib/cups/filter/pdftopdf (PID 13546)
Aug 22 20:34:32 desk cupsd[8733]: [Job 1401] Started filter /usr/lib/cups/filter/foomatic-rip (PID 13547)
Aug 22 20:34:32 desk cupsd[8733]: [Job 1401] Started backend /usr/lib/cups/backend/socket (PID 13548)
Aug 22 20:34:32 desk cupsd[8733]: REQUEST localhost - - "POST /printers/hp4050_pcl3_hpijs HTTP/1.1" 200 48086 Print-Job successful-ok
Aug 22 20:34:35 desk cupsd[8733]: hp4050_pcl3_hpijs pgtest 1401 [22/Aug/2021:20:34:35 -0400] total 1 - localhost Undelivered Mail Returned to Sender na_letter_8.5x11in -
Aug 22 20:34:35 desk cupsd[8733]: [Job 1401] Job completed.
(2)
@ firefox 91.0.1 / SafeMode
exec:
"Print ..."
page NEVER prints; no contact to printer
journalctl -f | grep -i cups
(empty / no logs)
(3)
@ brave 1.28.106
exec:
"Print ..."
page prints OK
journalctl -f | grep -i cups
Aug 22 20:38:27 desk cupsd[8733]: [Job ???] Request file type is application/pdf.
Aug 22 20:38:27 desk cupsd[8733]: [Job 1402] Adding start banner page "none".
Aug 22 20:38:27 desk cupsd[8733]: [Job 1402] Adding end banner page "none".
Aug 22 20:38:27 desk cupsd[8733]: [Job 1402] File of type application/pdf queued by "pgtest".
Aug 22 20:38:27 desk cupsd[8733]: [Job 1402] Queued on "hp4050_pcl3_hpijs" by "pgtest".
Aug 22 20:38:27 desk cupsd[8733]: [Job 1402] Started filter /usr/lib/cups/filter/pdftopdf (PID 13824)
Aug 22 20:38:27 desk cupsd[8733]: [Job 1402] Started filter /usr/lib/cups/filter/foomatic-rip (PID 13825)
Aug 22 20:38:27 desk cupsd[8733]: [Job 1402] Started backend /usr/lib/cups/backend/socket (PID 13826)
Aug 22 20:38:27 desk cupsd[8733]: REQUEST localhost - - "POST /printers/hp4050_pcl3_hpijs HTTP/1.1" 200 84561 Print-Job successful-ok
Aug 22 20:38:31 desk cupsd[8733]: hp4050_pcl3_hpijs pgtest 1402 [22/Aug/2021:20:38:31 -0400] total 1 - localhost CUPS - ArchWiki - -
Aug 22 20:38:31 desk cupsd[8733]: [Job 1402] Job completed.
(4)
@ kate 21.08.0
exec:
"Print ..."
page prints OK
journalctl -f | grep -i cups
Aug 22 20:41:29 desk cupsd[8733]: [Job 1403] Adding start banner page "none".
Aug 22 20:41:29 desk cupsd[8733]: [Job 1403] Queued on "hp4050_pcl3_hpijs" by "pgtest".
Aug 22 20:41:29 desk cupsd[8733]: REQUEST localhost - - "POST /printers/hp4050_pcl3_hpijs HTTP/1.1" 200 332 Create-Job successful-ok
Aug 22 20:41:29 desk cupsd[8733]: [Job 1403] File of type application/pdf queued by "pgtest".
Aug 22 20:41:29 desk cupsd[8733]: [Job 1403] Adding end banner page "none".
Aug 22 20:41:29 desk cupsd[8733]: [Job 1403] Started filter /usr/lib/cups/filter/pdftopdf (PID 13909)
Aug 22 20:41:29 desk cupsd[8733]: [Job 1403] Started filter /usr/lib/cups/filter/foomatic-rip (PID 13910)
Aug 22 20:41:29 desk cupsd[8733]: [Job 1403] Started backend /usr/lib/cups/backend/socket (PID 13911)
Aug 22 20:41:29 desk cupsd[8733]: REQUEST localhost - - "POST /printers/hp4050_pcl3_hpijs HTTP/1.1" 200 26129 Send-Document successful-ok
Aug 22 20:41:34 desk cupsd[8733]: hp4050_pcl3_hpijs pgtest 1403 [22/Aug/2021:20:41:34 -0400] total 1 localhost Untitled Letter one-sided
Aug 22 20:41:34 desk cupsd[8733]: [Job 1403] Job completed.
Here are debug-level cups logs for:
(1) print from Firefox: https://pastebin.com/dTNF9sDH
(2) print from TBird: https://pastebin.com/Sqhdnjus
Note that in case (1), it gets to
Sep 02 20:31:29 test cupsd[21164]: cupsdSetBusyState: newbusy="Not busy", busy="Not busy"
then
Sep 02 20:31:30 test cupsd[21164]: Expiring subscriptions...
and STOPs, with no further logged activity.
but in case (2), it similarly gets to
Sep 02 20:32:19 test cupsd[21164]: cupsdSetBusyState: newbusy="Not busy", busy="Not busy"
then sees another state change
Sep 02 20:32:19 test cupsd[21164]: cupsdSetBusyState: newbusy="Active clients", busy="Not busy"
and continues to a successful print. As mentioned, other apps also continue ...
Firefox print always appears to stop at the same point.
Not sure if that's useful/informative here, other than it's different than apps that do manage to print.
overriding setting default, to
user_pref("print.tab_modal.enabled", false);
successfully works around inability to print
with that mod, print to LAN appears to work -- at least in initial tests
this setting appears to be going away
settingRemove print.tab_modal.enabled pref and old print preview code
https://bugzilla.mozilla.org/show_bug.cgi?id=1702501
so, a workaround, not a fix. and the workaround goes away (soon?).
|
|
||
Comment 9•4 years ago
|
||
So the old dialog works, but "Print using the system dialog" (which does the ~same) doesn't? That's really odd...
|
||
Comment 10•4 years ago
|
||
Could you try mozregression again, now that you have it reliably failing again? (assuming it is still reliably failing, with print.tab_modal.enabled set to its default value of true)
Your observation in comment 3 about mozregression "fixing things" is quite surprising & seems unexpected; I'm guessing that was just a fluke/coincidence of some sort. Now that you can reliably reproduce things being broken in one configuration and working in the other configuration, I'm hoping maybe we can capture a regression range to know where to start looking here and who to point at this.
|
|
||
Comment 11•4 years ago
|
||
(Also, for what it's worth: the pastebins from your comment 7 expired within a few days, unfortunately - if you capture any more logs, would you mind attaching them using "Add attachment" on Bugzilla?)
|
||
Updated•4 years ago
|
|
||
Comment 12•4 years ago
|
||
(In reply to pgnet.dev from comment #8)
overriding setting default, to
user_pref("print.tab_modal.enabled", false);
successfully works around inability to print
with that mod, print to LAN appears to work -- at least in initial tests
this setting appears to be going away
settingRemove print.tab_modal.enabled pref and old print preview code
https://bugzilla.mozilla.org/show_bug.cgi?id=1702501so, a workaround, not a fix. and the workaround goes away (soon?).
I confirm this problem, and that this work-around allows me to print.
|
|
||
Comment 13•4 years ago
|
||
Would be interesting to see if this works for you on Nightly, as per bug 1747952.
|
|
||
Comment 14•4 years ago
|
||
I could try the nightly build. Is there an easy way to sandbox that? I don't really want it mingling with the rest of my system...
Thanks.
|
|
||
Comment 15•4 years ago
|
||
So assuming you untar then run it, the only thing it should alter is the ~/.mozilla folder, but it creates a separate profile from the release channel, so you can delete that afterwards and carry on... I think there's a nightly snap too, but that's not provided by Mozilla, IIRC
|
|
||
Comment 16•4 years ago
•
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)
So assuming you untar then run it, the only thing it should alter is the
~/.mozillafolder, but it creates a separate profile from the release channel, so you can delete that afterwards and carry on... I think there's a nightly snap too, but that's not provided by Mozilla, IIRC
(Just to be extra clear: emilio is not suggesting that you delete ~/.mozilla -- that's the top-level folder where all Firefox data is stored including your regular Firefox profile.
The thing that you'd want to delete (if you like) would be the Nightly profile folder which is probably a subfolder inside of ~/.mozilla/firefox; you can discover the specific profile folder by visiting about:profiles from inside Nightly, and it'll tell you "This is the profile in use" for whichever profile it's using. Or about:support has a line that shows the currently-in-use "Profile Directory", too.)
Alternately/also, you can just leave this folder alone; it will just store some settings from the few minutes that you test Nightly, and it won't bother your regular Firefox instance or anything else at all.)
|
|
||
Comment 17•4 years ago
|
||
(Also, RE the Nightly tarball: you can get that from https://nightly.mozilla.org/ , and just run the firefox binary from inside the folder that gets extracted from the tarball. It's fine to run it while you still have regular Firefox open, too.)
|
|
||
Comment 18•4 years ago
|
||
Nightly build firefox-98.0b2.tar.bz2 does not exhibit this same issue...
Does that make this an issue with my version of firefox... or with the Ubuntu-ized version of firefox that ships with KDE Neon...?
|
|
||
Comment 19•4 years ago
|
||
Just a guess, but does KDE Neon ship firefox as a snap? That might be an issue...
If not... maybe bug 1747952 fixed this? But that'd be a bit weird.
|
|
||
Comment 21•4 years ago
|
||
No. It is not a snap. It is a debian package.
|
|
||
Comment 22•4 years ago
|
||
Current version of Firefox in Ubuntu/Neon from .deb sources: 96.0+build2-0ubuntu0.20.04.1
|
|
||
Comment 23•3 years ago
|
||
cjd, pgnet, is this bug still happening for you?
If so, if you open the page about:support#printing and click on the "Clear saved print settings" button in the "Printing" section, does that resolve things? (I ask since Nightly seems to work, based on comment 18.)
|
Reporter | |
Comment 24•3 years ago
|
||
@jwatt
here, it never worked here on FF 9X.X
once mv'd to FF 102+, all's good; printing with, or without, systemd dialog, works as expected
for ref,
lsb_release -rd
Description: Fedora release 36 (Thirty Six)
Release: 36
rpm -qa | egrep "firefox|cups"
cups-2.4.2-4.fc36.x86_64
cups-client-2.4.2-4.fc36.x86_64
cups-filesystem-2.4.2-4.fc36.noarch
cups-filters-1.28.15-1.fc36.x86_64
cups-filters-braille-1.28.15-1.fc36.x86_64
cups-filters-libs-1.28.15-1.fc36.x86_64
cups-ipptool-2.4.2-4.fc36.x86_64
cups-libs-2.4.2-4.fc36.x86_64
firefox-104.0.1-1.fc36.x86_64
firefoxpwa-2.0.3-1.x86_64
gutenprint-cups-5.3.4-8.fc36.x86_64
python3-cups-2.0.1-12.fc36.x86_64
|
|
||
Comment 25•3 years ago
|
||
Thanks, pgnet. cjd, if this is still happening for you we can reopen.
Description
•