Lazily add mDNS/Bonjour/Avahi printers to the print UI on CUPS platforms (missing printers)
Categories
(Core :: Printing: Setup, enhancement, P2)
Tracking
()
People
(Reporter: alaskanemily, Unassigned)
References
Details
(Whiteboard: [print2020][old-ui-][layout:backlog])
We are ignoring mDNS/Bonjour printers current with 1663920 as they may be slow to access. We could add them to the list of supported printers by fetching info for them with a different call to GetPrinters (perhaps something like GetDiscoveredPrinters?), so that we show the printing UI without waiting for them, but still display them as options if we find them.
Updated•4 years ago
|
Updated•4 years ago
|
![]() |
||
Updated•4 years ago
|
![]() |
||
Updated•4 years ago
|
![]() |
||
Updated•4 years ago
|
Reporter | ||
Comment 1•4 years ago
|
||
To elaborate on what this bug is:
We currently ignore any Bonjour/Avahi printers and expect the user to use the system print dialog if they want to print using one. The reason is that enumerating these printers can take a long time, since the list isn't stored by CUPS (usually locally on the machine) and instead results in network requests to find what devices respond. We don't want to wait for that to occur before we bring up the print dialog.
However, we could both provide Bonjour/Avahi printer support and bring up the dialog with the current method if we, after populating the printer list as we currently do without Bonjour/Avahi printers, we sent a second request to find such printers and added them to the printer list when we do finally get a response.
We would probably want to indicate to the user that more printers might be coming to the list when the dialog initially loads. If the current default is a Bonjour/Avahi printer, we do just load the last used print settings so we could reasonably show that printer with those settings before the actual network response occurs. We will however need additionally indicate if this printer is unavailable, which may take place after the print preview is fully displayed and has that printer selected.
Comment 3•3 years ago
|
||
[Transferring "blocks bug 1702501" relationship from bug 1722063 which I've duped over here]
![]() |
||
Comment 4•3 years ago
|
||
FWIW, assuming the patch for bug 1747952 lands as it currently is, Firefox on Linux/macOS will now look for network printers that are not set up and there will be a pref print.cups_enum_dests_timeout_ms to control how long it looks for.
Updated•3 years ago
|
Comment 5•3 years ago
|
||
Emily is this a dupe of bug 1771500?
Reporter | ||
Comment 6•3 years ago
|
||
I think they are slightly different. I did some investigation, and the method used by that change causes CUPS to check for Bonjour/mDNS printers, but with a very short timeout. The idea with this bug was that we would use a fairly long timeout (probably several seconds at least), and then add in printers we found with that method.
This bug is also specifically about not having any timeout added when we first create the UI, and then adding in the printers we do find afterwards, rather than doing this before the initial UI display.
Comment 7•3 years ago
|
||
So, long story short, it would be in our best interests to keep this bug and associated epic in queue?
Reporter | ||
Comment 8•3 years ago
|
||
Yes, this is for a more extensive change that will be more reliable for very slow or flakier networks or print servers (as well working when connected to a remote print server, otherwise CUPS won't enumerate Bonjour/mDNS printers just from Bug 1771500 without further work as here: https://github.com/apple/cups/blob/23c45db76a8520fd6c3b1d9164dbe312f1ab1481/cups/dest.c#L1691-L1708 ), but this requires a lot more work to implement.
Description
•