Affected versions

• Fx82.0a1

Affected platforms

• Windows 10

Steps to reproduce

1. Launch Firefox.
2. Access the following link.
3. Open the new modal print preview.

Expected result

• The print preview is opened in a short amount of time.

Actual result

• The preview only opens after 20 seconds of waiting time.

Regression range

• This seems to be a recent regression. Will come back with a regression range ASAP.

Additional notes

• The issue only reproduces on my Windows 10 machine.

Also attaching the information from about:support if it helps.

Last known good build: 2020-09-13
First known bad build: 2020-09-14
Changeset: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=48f10c4139655c2c4d52fa773f1fd760ea681d42&tochange=6450088b6b73ffc17c79cd7097b1bfe30d00e207

Thanks for the regression range, Cristian. That's very helpful.

I guess the new OpenPrinterW call added in https://phabricator.services.mozilla.com/D90091 for bug 1663494 is responsible. Any thoughts, Jonathan/Bob?

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

Thanks for the regression range, Cristian. That's very helpful.

I guess the new OpenPrinterW call added in https://phabricator.services.mozilla.com/D90091 for bug 1663494 is responsible. Any thoughts, Jonathan/Bob?

I don't see anything else and that would certainly be a likely candidate.
Looks like the reverse implication of the notes in the documentation for OpenPrinter (i.e. that OpenPrinter is generally fast) may not by true.
It would be interesting to see if we can see this in the telemetry.

Wow, that's terribly slow! I wonder: Cristian, do you have one or more network-connected printers set up on that machine (as distinct from local USB-connected or similar)? Are any of them currently not available (e.g. because they're on some other network that you're not currently connected to)?

So the OpenPrinter call there was added in order to remove printers from the list if they're not actually usable, e.g. due to Windows permissions settings. I guess an alternative would be to leave them in the list, and remove/relax the DIAGNOSTIC_ASSERTs that people can hit if such a printer is actually selected.

As I understand it, this would change the UX somewhat: instead of such an inaccessible printer being hidden from the UI, it'll be there, but if the user tries to print to it we'll throw an error at some later point. (I wonder, will we hit errors trying to retrieve paper sizes, margins, etc?) We should be able to handle such errors cleanly, but still, the UX seems less streamlined than if we simply hide the printer from the list altogether.

Maybe we should keep track of whether printers are local or network, and skip the OpenPrinter call for network printers -- those would be left in the list, and any access failures will need to be handled cleanly later in the process.

If you select Nightly here: https://sql.telemetry.mozilla.org/queries/74846#186975
You can see the uptick after this landed.
Probably barely noticeable for 95%, for the next 4% annoying and 1% pretty terrible.

Hey Jonathan,
Yes, I do have a network printer setup that is not currently available, but that is not set as the default printer so I don't understand why it still hangs. Maybe a solution where we call directly the default printer (if that is at all possible).
Handling the failures later in the process sounds good and would be more desireable if this is possible from a technical perspective.

I think something like this ought to help. I've started a tryserver build at https://treeherder.mozilla.org/#/jobs?repo=try&revision=3430034d7b167ba436a89e4f0aeb45e59a65e6c7, so if you could test that once it becomes available and confirm if the slowness is gone, that would be great -- thanks.

I guess the other thing to test would be what happens if you choose your (unavailable) network printer as the destination, and try to submit a print job. If that ends up hitting one of our DIAGNOSTIC_ASSERTs, we should probably re-examine that and handle it more nicely.

https://hg.mozilla.org/mozilla-central/rev/4b2034927979

Setting up the flag and regressed by field based on Comment 4.

Can you request Beta uplift? We're seeing a spike in the >10s print preview setup telemetry: https://mzl.la/2HotK97

Comment on attachment 9176878 [details]
Bug 1665272 - Don't attempt to call OpenPrinter on network printers when collecting the printer list. r=bobowen

Beta/Release Uplift Approval Request

• User impact if declined: Print preview may be very slow to open for some users, depending on printers configured in the Windows list.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Per comment 8:

• ensure print.tab_modal.enabled is true
• configure a network-connected printer
• then disconnect it so that it is unavailable
• check for a long delay opening the Print UI

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Partially reverts change from bug 1663494, so we don't attempt to filter network-connected printers.
• String changes made/needed:

Sorry it took such a long time to respond, but I had to get a machine with a network printer setup (was removed on mine).
The issue is fixed on the latest nightly build. Loading time for the print preview is of 1-2 seconds on machines that have network printers set up, but unavailable.

Comment on attachment 9176878 [details]
Bug 1665272 - Don't attempt to call OpenPrinter on network printers when collecting the printer list. r=bobowen

approved for 82.0b4

https://hg.mozilla.org/releases/mozilla-beta/rev/53e2d9af47ad

Tested using the latest beta Fx82.0b4. The print preview is generated quite fast in comparison with the previous affected versions.
I verified this on Windows 7 and Windows 10 with network printers setup, but unavailable.