Affected versions

• Latest 83.0a1
• 82.0b4

Affected platforms

• Ubuntu 20.04

Steps to reproduce

1. Launch Firefox (make sure print.tab_modal.enabled is set on true)
2. Open any page
3. Hit Ctrl +P
4. Select your printer from the Destination dropdown.

Expected result

• The printer is correctly selected.

Actual result

• The printer is not displayed in the Destination dropdown.

Regression range

• It seems to be a regression since it does not reproduce on Fx 81.
  Might be related to bug 1657164.

Additional notes

• The printer is displayed on the system dialog and can be used correctly with this option.
• Issue persists after printer reinstall as well.
• The printer in use is a HP MFP M28a.

Suggested severity

• S2, since I'm unable to use the printer from the new modal but can use it from the system dialog.

Regression range

• Last Good Nightly: 2020-09-24
• First Bad Nightly: 2020-09-25
• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2b2e72856dc138c848da111f81a83456360c671c&tochange=726cb6cf323ddfc65d110f88b5bdd952f5024092

It seems that this was caused by bug 1663920.
Hiro, could you please take a look?

I think this behavior was expected if your printer is a network printer that hasn't been added to your system printers. Hiro and Emily can maybe comment further.

Does Chrome list this printer?

Yes, we recently changed how auto-discovered printers are handled. I believe the intention is that to access auto-discovered printers, you should use the system dialog for the time being.

There is also bug 1666937 which details an alternative way to provide auto-discovered printers (adding them to the list in a second pass). That would let the user select them from the current dropdown, but would not put the printers into the dropdown when the page initially loads.

(In reply to Jonathan Watt [:jwatt] from comment #3)

Does Chrome list this printer?

Yes, Chrome does list the printer. Also, it is connected via USB, it's not a network printer.

Thanks.

What I don't quite understand is, as I understand CUPS_PRINTER_DISCOVERED is a flag for printers which have just discovered but haven't been configured in the system, so I understand the printers can't be used as it is. And once after the printers have been properly configured, the flag should be removed, but I might have been misunderstanding it.

On Ubuntu (20.04) when a USB printer is connected, udev triggers /lib/udev/udev-add-printer script then it ends up calling cupshelper.activateNewPrinter, it ends up doing IPP_RESUME_PRINTER and CUPS_ACCEPT_JOBS for the printer. I can't find where CUPS_PRINTER_DISCOVERED flag is removed.

This seems problematic in ways maybe we didn't fully anticipate, since a discovered printer could just be USB-connected and then expected to be available. I wrongly thought it was only for Bonjour or other network-discovered printers. I'll triage as such. Would the same also be true on macOS? I'm assuming it would but not sure.

A problem here is for both Mac and Linux we use CUPS APIs, CUPS is a some sort of abstract layer, but in reality it totally depends on how the system configures printers in the system. The default paper size is one of the problems caused by the difference, and this is probably also one of such problems.

Hiro: Do you have ideas on how to get around this? If we don't ignore CUPS_PRINTER_DISCOVERED it sounds like we get hangs when users use those printers, but if we do ignore them they don't show up when they might be expected.

I have no idea right now, but I will find a way to tell whether the printer is via USB or not, to avoid filtering them out.

I honestly don't quite understand what we can do here. My father has a printer which is able to be connected via USB, so I borrowed it and tested.

The printer is Canon PIXUS TS8230, when I connected it to my Ubuntu 20.04 box, it didn't appear in the system setting, so I tried to add it manually but it fails to install a driver which seems to has been installed by default on my Ubuntu, thus the printer appeared in the system setting, but its state is not properly configured. Thus the printer state is still CUPS_PRINTER_DISCOVERED, then it didn't appear in our print preview UI.

Then I tried to install a different driver downloaded from the manufacture site, after that, the printer has appeared in our print preview UI, that mean its state is no longer CUPS_PRINTER_DISCOVERED.

So, at least on my environment, a USB printer works fine with filtering CUPS_PRINTER_DISCOVERED after installing a proper driver for the printer.

Cornel, how did you setup the printer in question?

I am suspecting whether a given printer keeps as CUPS_PRINTER_DISCOVERED is depending on the printer drivers.

I just realized the printer which hasn't properly configured is NOT listed in /etc/cups/printers.conf, there is no corresponding PPD file in /etc/cups/ppd either.

It may be possible that the printer in question might have been filtered out by CUPS_PRINTER_SCANNER.

Cornel can you also try this binary? This binary doesn't filter out scanners.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5d8ef99db59f770f488e7b7a3d3c75682f271f1d

(In reply to Hiroyuki Ikezoe (:hiro) from comment #13)

Cornel, how did you setup the printer in question?

I've installed the printer using hplip: https://developers.hp.com/hp-linux-imaging-and-printing/install/install/index and it worked correctly before Sep 25.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #15)

Cornel can you also try this binary? This binary doesn't filter out scanners.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5d8ef99db59f770f488e7b7a3d3c75682f271f1d

With this binary, the printer is still not displayed in the new modal.

I tried to install the driver but it cannot be installed.

When I choose automatic install, it tries to install python-pyqt5 but the corresponding package name on Ubuntu 20.04 is python3-pyqt5, even if after I manually installed python3-pyqt5, the installer fails.

When I choose custom install and skip installing the python-pyqt5 package, it still fails on "BUILD AND INSTALL" section. I'd say, it's broken. :/

Anyway, I did push another try build with using cupsEnumDest instead of using cupsGetDests and ignoring CUPS_PRINTER_SCANNER. This approach has a problem on my Ubuntu 20.04, but hopefully it fixes the issue on Cornel's environment.

Here is the link to the try, https://treeherder.mozilla.org/#/jobs?repo=try&revision=77834af4c42c46f455927b78d343b6b51bf1aaa4, unfortunately as of now either treeherder or try server seems not to work properly, if the try build doesn't appear, I will push another try later.

Hey Cornel, can you please another try build in comment 17? Thanks!

Confirming that the printer is displayed in the new modal and works with the try build from comment 17.

Thank you Cornel! I will go with the way using cupsEnumDest.

It looks like the combination of cupsGetDests and filtering
CUPS_PRINTER_DISCOVERED filters a certain type of printers which shouldn't be
filtered.

As I wrote [1], cupsEnumDests didn't filter out a printer which hadn't been
configured in the system, but the printer didn't make opening the print preview
window slow at all, so it would be better than the case where users can't use
printers at all.

[1] https://phabricator.services.mozilla.com/D90508#2928340

https://hg.mozilla.org/mozilla-central/rev/3926178e4b42

Confirming that the printer is now properly displayed within the new modal using Fx 83.0b2 on Ubuntu 20.04 x64.
Stress-tested it for a while by connecting/disconnecting the printer and the printer status was updated correctly each and every time.

Thanks!