Bug 1983403 - Firefox does not see printers connected in wifi
Summary: Firefox does not see printers connected in wifi
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 36
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Jan Horak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-07-18 10:03 UTC by xzj8b3
Modified: 2022-05-30 13:28 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
Firefox non vede stampanti connesse in wifi (274.88 KB, image/png)
2021-07-18 10:03 UTC, xzj8b3
no flags Details
more than enough printers shown screenshot (38.69 KB, image/png)
2022-05-27 14:20 UTC, Jan Horak
no flags Details

Description xzj8b3 2021-07-18 10:03:33 UTC
Created attachment 1802885 [details]
Firefox non vede stampanti connesse in wifi

Firefox does not see printers connected to wifi, it is true that it allows you to save in PDF and print with other software, but I find it rather annoying to perform various operations when it would only take two clicks and this is why some components are not updated and do not work properly ... Gnome is now Desktop defaulth, which is pushed more to support more properly each feature, especially those used more constantly!

Comment 1 Martin Stransky 2021-07-19 20:41:21 UTC
Is the Wifi printer seen by other system components? Do you see the printer if you go to CUPS config page, i.e. open this URL in your browser:

http://127.0.0.1:631/

Thanks.

Comment 2 xzj8b3 2021-07-20 11:49:21 UTC
(In reply to Martin Stransky from comment #1)
> La stampante Wifi è vista da altri componenti del sistema? Vedi la stampante
> se vai alla pagina di configurazione di CUPS, cioè apri questo URL nel tuo
> browser:
> 
> http://127.0.0.1:631/
> 
> Grazie.

No it does not see it, how can I add it correctly?

Comment 3 Martin Stransky 2021-07-21 09:06:07 UTC
Then it's a problem with your CUPS configuration - please look for CUPS documentation for that (https://www.cups.org/).

Comment 4 Zdenek Dohnal 2021-07-29 04:47:59 UTC
Applications can see the printers even without their installation as a permanent queues in CUPS - the technology is called CUPS temporary queues[1] and it was in 2016.

If you don't see the printer without installation in the application, then the toolkit or the application which implemented print dialog doesn't support this tech and should be updated.

I'm not sure which toolkit firefox uses by default (because I guess the button 'Print using the system dialog' means GTK print dialog), so switching back to firefox.


[1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Print_queue

Comment 5 Zdenek Dohnal 2021-07-29 04:51:51 UTC
correction: 'it was introduced in 2016'

Comment 6 xzj8b3 2021-08-12 20:48:01 UTC
(In reply to Martin Stransky from comment #1)
> Is the Wifi printer seen by other system components? Do you see the printer
> if you go to CUPS config page, i.e. open this URL in your browser:
> 
> http://127.0.0.1:631/
> 
> Thanks.

I have temporarily abandoned Fedora .... Too many heat problems with open graphics drivers and Gimp does not show up for those who love a little photo editing .... Photoshop is another thing .... also you always have to fight to show simple printers in wifi ... at this point then better a break from Fedora, moreover it installs too many components that to many seem only an obstacle for a common desktop use on a 15 laptop

Comment 7 Zdenek Dohnal 2022-03-04 05:39:32 UTC
I can reproduce in Fedora 36 as well. Can you send the RFE upstream? Temporary printing queues will be default for desktops in the future. Libreoffice and GTK-based applications support them at the moment.

Comment 8 Jan Horak 2022-05-09 07:28:18 UTC
Does the Print using the system dialog… shows all the printers?

Comment 9 Zdenek Dohnal 2022-05-09 08:14:13 UTC
GTK currently does their own discovery via mDNS, and then if user chooses the printer, GTK sends CUPS-Create-Local-Printer operation into CUPS, which will create the temporary queue - https://openprinting.github.io/cups/doc/spec-ipp.html#CUPS_CREATE_LOCAL_PRINTER .
,
Otherwise you can use cupsGetDests2() API function as Libreoffice does for listing all printers, or cupsGetNamedDests(), which will get you a single destination.

Comment 10 Jan Horak 2022-05-24 13:50:54 UTC
Interestingly I can see the printer I have not installed before to the cups in the dialog but only after showing the print dialog for the second time. Do you also see this behavior? Or could you give us some hints how to emulate such printer on the local network?

Comment 11 Jan Horak 2022-05-24 14:32:33 UTC
It looks like the dialog is not waiting long enough before enumeration of the network printers finishes. Zdenek, do you have any hints how to setup test environment? Now I'm seeing the network printer always in the print dialog.

Comment 12 Zdenek Dohnal 2022-05-24 15:54:41 UTC
(In reply to Jan Horak from comment #10)
> Interestingly I can see the printer I have not installed before to the cups
> in the dialog but only after showing the print dialog for the second time.

Hmm, interesting - haven't you switched into system print dialog (GTK) in the meanwhile? GTK dialog can make the temporary queue permanent for a while (basically that's how temporary queue works - it is seen only on mDNS and when it is needed, it is created by special operation Create-Local-Printer. Such queue has a limited time frame when it exists and then it is removed - but in this timeframe it behaves as permanent, accessible with IPP_GET_PRINTERS operation, which causes confusion a lot ).


Other thing which can be in play is cups-browsed service, which automatically installs the device found on local network (read it as found on mDNS communication) locally as permanent queue, making it visible to all applications. Maybe cups-browsed was renewing your printer at the time you've opened the Firefox default dialog?

>
> Do you also see this behavior?

I haven't seen this specific behavior yet :(

> Or could you give us some hints how to
> emulate such printer on the local network?

Just note - not all network printers are available via temporary queues - only those capable and set to use AirPrint, IPP Everywhere, Wifi direct, IPP-over-USB or Mopria standards.

You can get a mock printer, which will be available on localhost (file_test.ppd is a ppd of some locally installed print queue):

$ sudo ippeveprinter -D file:/tmp/ps -P /etc/cups/ppd/file_test.ppd -c /usr/bin/cat "local_printer"


This way you will get a printer available on mDNS and it is listening on port 8000.

Comment 13 Zdenek Dohnal 2022-05-25 06:14:13 UTC
(In reply to Zdenek Dohnal from comment #12)
> Just note - not all network printers are available via temporary queues -
> only those capable and set to use AirPrint, IPP Everywhere, Wifi direct,
> IPP-over-USB or Mopria standards.
> 

To be precise here and prevent possible misinterpretations - the printers mentioned above are supported by temporary queues by default, without additional layer. Printers which don't support such standards have to use a printer application, which will provide them IPP 2.0 interface.

ippeveprinter is one of such printer applications, which can be used in examples. The ippeveprinter command above will do following:

- it will create a local_printer service on mDNS communication, which will listen on localhost:8000
- it will use a certain PPD (printer driver) which defines printer options
- the output will be saved in /tmp/ps
- 'cat' will be used for filtering if a job arrives - so the printer will just copy the incoming file into /tmp/ps file

Comment 14 Jan Horak 2022-05-25 16:27:50 UTC
Hm, Firefox is using cupsEnumDests, which should call the cupsGetDests: https://searchfox.org/mozilla-central/source/widget/nsPrinterListCUPS.cpp#88
When running:

sudo ippeveprinter -D file:/tmp/ps -P /usr/share/ppd/cupsfilters/Generic-PDF_Printer-PDF.ppd -c /usr/bin/cat "remote_printer10"

I can see the new printer in the dialog immediately. I've even tried to run ippeveprinter on different machine to emulate remote device and it also works. Are you able to reproduce the issue with the ippeveprinter (just make sure you're passing valid ppd file, otherwise the printer does not show up in LO or Firefox, only in GTK dialog with Refusing jobs status)?

Comment 15 Zdenek Dohnal 2022-05-26 05:32:01 UTC
Ok, so:

$ ls /usr/share/ppd/cupsfilters/Generic-PDF_Printer-PDF.ppd
/usr/share/ppd/cupsfilters/Generic-PDF_Printer-PDF.ppd

So I have the same PPD...

$ sudo ippeveprinter -D file:/tmp/ps -P /usr/share/ppd/cupsfilters/Generic-PDF_Printer-PDF.ppd -c /usr/bin/cat "remote_printer10"
[sudo] password for zdohnal: 
Listening on port 8000.
Ignored Avahi state 2.
...

$ lpstat -e
hp_laserjet
HP_LaserJet_M1536dnf_MFP_42307C_
remote_printer10                     <-------
tpbb-test
tpbc-north

Looks like the printer is seen by CUPS, but Firefox doesn't see it.

Are you really sure you don't have cups-browsed running?

Please try 'lpstat -a' and 'lpstat -e' and compare the results - 'lpstat -e' should have one more queue, the temporary one. If the lists of printers are identical, there is something which makes the queues permanent, so they are seen everywhere (because permanent queues are shown via old API), probably cups-browsed. Or if you use a print server and have some quirks for connectivity (ServerName in /etc/cups/client.conf or ~/.cups/client.conf or a specific CUPS environment variable for this), you see the permanent queues on the server itself.

Comment 16 Jan Horak 2022-05-27 13:48:59 UTC
With cups-browsed disabled I'm able to reproduce the issue reliably, filled upstream bug with further info:
https://bugzilla.mozilla.org/show_bug.cgi?id=1771500

Comment 17 Jan Horak 2022-05-27 14:20:11 UTC
Created attachment 1884186 [details]
more than enough printers shown screenshot

Hm, after applying patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1771500 I see a lot of more printers, some of them duplicated. It seems to be because they're available over ipp and also ipps. Should I do the filtering on the Firefox site or is there more suitable approach?

Comment 18 Zdenek Dohnal 2022-05-30 13:28:04 UTC
(In reply to Jan Horak from comment #17)
> Hm, after applying patch in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1771500 I see a lot of more
> printers, some of them duplicated. It seems to be because they're available
> over ipp and also ipps. Should I do the filtering on the Firefox site or is
> there more suitable approach?

cupsGetDests2() instead of cupsEnumDests() should do the trick - showing the only one entry for a device. cupsEnumDests() doesn't call cupsGetDests(), but internal cups_enum_dests(), see https://github.com/OpenPrinting/cups/blob/master/cups/dest.c#L980 .

cupsGetDests2() calls cups_enum_dests() as well, but with a slightly different options than Firefox does - https://github.com/OpenPrinting/cups/blob/master/cups/dest.c#L1708 . cupsGetDests2() is used in lpstat as well, which doesn't show duplicates based on IPP/IPPS and IPv4/IPv6.

The comment from the cupsEnumDests() function warns about the duplicity:

 964  * Note: The callback function will likely receive multiple updates for the same
 965  * destinations - it is up to the caller to suppress any duplicate destinations.


Note You need to log in before you can comment on or make changes to this bug.