User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Simply press Cmd+P (or Print)

I was able to consistently reproduce it by having Printopia (v. 2) installed, a virtual printer that advertises itself in the network via Apple's Bonjour network discovery protocol. Disabling it made the issue dissappear. My actual printer is connected via AirPrint (also wireless) and I couldn't reproduce the problem with only an AirPrint-connected printer.

Note: It seemed to resemble a lot like another issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1662946#c20) but I was requested to create a separate ticket.

Actual results:

The new print dialog appears, but keeps spinning creating the preview, for even the simplest pages around.

Expected results:

The preview page should show up quickly, as happens when I switch to the old (system) UI or when I switched the virtual bonjour printer off.

I didn't see any new messages bubble up in Browser Console, nor Web Console.

Toggling the old UI (print.tab_modal.enabled) was instantenous in every scenario.

Thanks for spinning this out into a separate bug. The symptoms are similar but the cause is different (and therefore the solution will be different too).

I wonder how Chrome manages to avoid this (I assume it does). Does Chrome offer the virtual printer as an option in its printing UI?

Chrome has the option to show more destinations, which actually takes a short while to populate, but never shows any of the Bonjour printers if they haven't actively been added as a printer in the macOS "Printers & Scanners"-preferences (by default this virtual printer is just a printer that advertizes itself as a printer available to all machines in the network, but it is not a printer added to the printerlist).

While writing this comment I opened another tab (in trusted Firefox 82) trying to print, and while it seems as if it has gotten quicker, it is still slow (1 minute wait, instead of 10 mins?) and it still lists all printers that are broadcasting on the network, including ones I did not actively add as a printer in the macOS "Printers & Scanners"-preferences pane.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

The old UI (print.tab_modal.enabled: false) btw lists these other Bonjour printers as 'Nearby printers'. I can't get these printers to show up in Chrome.

Is it possible that the mac build I posted in bug 1661157 comment 29 solves this?

Maaten, would you mind trying the build?

@:hiro, I(In reply to Hiroyuki Ikezoe (:hiro) from comment #5)

Is it possible that the mac build I posted in bug 1661157 comment 29 solves this?

This build indeed solves the issue! (recreated the failing situation in the current nightly, closed it, opened the special build by :hiro, worked as desired). To me it totally makes sense not to show any 'nearby/alternative' printers that are not actively added as printers to the operating system, and have it something that a user needs to actively add (or at least actively search for in a deeper pane).

@:jwatt, @:hiro, still sure that #1662946 is not related?

(In reply to Maarten Brouwers from comment #7)

@:jwatt, @:hiro, still sure that #1662946 is not related?

Right, now I believe it's a different issue.

I've poked around on MacOS, and now I am ~100% sure we should ignore CUPS_PRINTER_DISCOVERED. It's just printers not yet added to the system. When I choose the printers which is not yet added to the system on the print preview and print to the printer, it silently fails.

Hiro: Would you be able to take this on based on the approach in comment 9? Per feedback from alaskanemily: It might help to think about interaction with CUPS using Avahi on Linux as well.

Sure.

For records/future references;

On my Ubuntu 20.04 there are two printer entries, "HP_ENVY_5540_series_B0742A_" and "HP_ENVY_5540_series_B0742A_@HPEC8EB5B0742A.local" in the system setting and on current Nightly both appear in the print preview. With ignoring CUPS_PRINTER_DISCOVERED, only "HP_ENVY_5540_series_B0742A_@HPEC8EB5B0742A.local" appears there. Interestingly on a chromium installed via snap on the Ubuntu both printers appear in the chromium's print preview. I was wondering because as far as I can tell chrome also ignores CUPS_PRINTER_DISCOVERED as I wrote in bug 1661157 comment 29. Today I finally succeeded in launching a local built chromium and confirmed there is only one printer entry which is the .local suffix one. I've also confirmed that there is only one printer in the print preview both on a chrome canary and a released versions (85.0.4183.102-1) of chrome downloaded from google directly. So I think the snap version of chrome is somewhat patchy (I think it's a wrong patch).

Now I am pretty sure ignoring CUPS_PRINTER_DISCOVERED is also the right thing to do on Linux.

I am afraid it took some amount of time. (the local built version of chromium crashes at startup, I had to find a workaround for the crash).

https://hg.mozilla.org/mozilla-central/rev/726cb6cf323d

Comment on attachment 9176204 [details]
Bug 1663920 - Ignore CUPS_PRINTER_DISCOVERED, CUPS_PRINTER_FAX and CUPS_PRINTER_SCANNER in the CUPS backend. ?AlaskanEmily

Beta/Release Uplift Approval Request

• User impact if declined: Some Mac users can end up with "preparing print preview" spinning for a very long time.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky):
• String changes made/needed:

Comment on attachment 9176204 [details]
Bug 1663920 - Ignore CUPS_PRINTER_DISCOVERED, CUPS_PRINTER_FAX and CUPS_PRINTER_SCANNER in the CUPS backend. ?AlaskanEmily

approved for 82.0b4

https://hg.mozilla.org/releases/mozilla-beta/rev/701d6a99450e

(In reply to Maarten Brouwers from comment #0)

I was able to consistently reproduce it by having Printopia (v. 2) installed, a virtual printer that advertises itself in the network via Apple's Bonjour network discovery protocol. Disabling it made the issue dissappear. My actual printer is connected via AirPrint (also wireless) and I couldn't reproduce the problem with only an AirPrint-connected printer.

Maarten, can you test the latest Nightly from https://nightly.mozilla.org/ and check that the hang is fixed, and that your other wireless printer can still be used?

Sorry, not a regular visitor of bugzilla (only when things really bother me :o ), but this was fixed indeed. Thank you very much for all those who've worked on it! :)