1821588 - Print Preview hanging (due to disconnected print_printer value)

Status: RESOLVED WORKSFORME

(Core :: Print Preview, defect, P3)

Description

[Tony Davis]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

Tried to print an Amazon Return label from the laptop. The printer chosen was on the currently booted desktop shared printer:
\TONY-PCW7\HP_Photosmart_D7200_series

Actual results:

The print preview hung with rotating graphic.

Expected results:

The print preview should have displayed.
NOTE: The current default printer is the correct one, BUT I am in the middle of completing a new Windows 11 desktop, with the same printer named:
\TONY-WIN11\HP_Photosmart_D7200_series_(Copy_1), that I HAVE recently printed to. I noticed that in the config, the item print_printer was set to that printer, but that system was NOT online.
When I changed that item value to:
\TONY-PCW7\HP_Photosmart_D7200_series the preview worked, and I could print OK. Maybe some internal code is forgetting to dynamically manage that setting string?

Comment 1

[Tony Davis]

Attachment: ABOUT_SUPPORT_BUG_1821588.txt

Comment 2

[Rares Doghi, Desktop QA]

Moving the component for this issue.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:emilio, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Yeah this looks annoying (though somewhat uncommon).

If you can repro this again by changing the print_printer string, is there any chance you could take a profile of the issue using https://profiler.firefox.com/? That'd help understand where time is getting spent. Sorry for asking you this but I don't have the setup to repro myself right now, I'll try to find if someone on the time can have that tho.

Thanks!

Comment 5

[Tony Davis]

Hello, thanks for info on the useful profiling performance tool. We are on vacation visiting relatives right now, and I won't be able to get that information for at least 2 weeks. When back home I will read the tool documentation, and try to reproduce the bug.

Comment 6

[Daniel Holbert [:dholbert]]

Some notes from interpreting the about:support data and comment 0 a bit:

1. It looks like the Firefox installation in question is on a Windows 10 machine (based on about:supprot)
2. That machine seems to have two network printers set up, as printers shared by other Windows hosts on the network -- those hosts being TONY-PCW7 and TONY-WIN11. (running win7 and win11, I assume? Or maybe the pcw7 one is the local win10 machine.)
3. At the time that this bug reproduced, Firefox had the TONY-WIN11 shared-printer as its most-recently-used (and hence default) print target (that's what the print_printer preference represents). However, TONY-WIN11 was offline.
4. This resulted in Firefox hanging while setting up its print-preview.

Let me know if I'm missing anything. Hopefully the performance profile helps us piece together what's going on -- or if not, maybe we can independently reproduce by setting up a local scenario like this^ (modulo any corrections for variables that I might have wrong).

Comment 7

[Tony Davis]

Hello, still away visiting relatives right now, but to clarify the STR systems:
The TONY-PCW7 was originally a Windows 7 PC, but is now Windows 10 22H2, and currently has the active HP printer attached. I never bothered to rename it! The TONY-WIN11 PC is my new self-built system running Windows 11, and I have been testing it on-and-off for the last few months. It does not have all of the required software on it at the moment (notably MS Office 2021), but I DID test that the HP printer directly connected to it (via USB) would share OK and work from the laptop (LAPTOP-TD-CD running Windows 10 home), which it did.

The TONY-WIN11 PC was then turned off, and the printer was then re-attached back to the original host TONY-PCW7, and the LAPTOP-TD-CD default printer changed back to the TONY-PCW7 one. However, the print preview unexpectedly hung, and this is when this BUG report was created.

Comment 8

[Daniel Holbert [:dholbert]]

Thanks for those additional details.

Once you're back home, please do capture and share a profile of the hang, using the toolbar-button that you can enable at https://profiler.firefox.com/ , and that'll hopefully give us some good clues about what's going on. Thanks!

Comment 9

[Tony Davis]

THREE PROFILE PERFORMANCE FILES CREATED. I hope these are useful
https://share.firefox.dev/3oNfY5K (first one that worked OK to the connected TONY-WIN11 PC printer that was connected temporarily)

https://share.firefox.dev/3LA4D1V (second one that tried to go to disconnected printer and looped on the preview graphic, and never displayed the preview and asking what printer to use).

However, when I stopped the profiler and uploaded it, and then went back to look at the printer preview loop, it had stopped at the printer selection UI)

https://share.firefox.dev/424sOL4 (Third one worked OK after I changed to default printer to the TONY-PCW7 PC Printer).

NOTE: I cannot use the original page that was a script driven site return label print attempt, as it is no longer available or valid for use. However, I think I partially reproduced this problem, in the second profile performance file.

Comment 10

[Daniel Holbert [:dholbert]]

Thanks! jwatt, I think you've looked at Windows print-dialog hangs in the past -- can you tell from the second profile there what might've gone wrong, or do you have any theories about related bugs or possible explanations here?

(side note: for whatever rerason, that second profile didn't capture any information from the content process, the one that's labeled ⁨https://electronics2000.co.uk⁩ in your third profile. For some sorts of bugs, that track would be important to take a look at -- but I think that's probably not important here since the Parent process would be the one to do the actual communication with the printer.)

At first glance, the good-news/bad-news is that nothing seems to be pegging the CPU when the print dialog is stuck. Good news that we're not death-spiralling, but bad-news since it means it's harder to see why we're stuck.

Comment 11

[Daniel Holbert [:dholbert]]

Tony, one other request -- could you try opening the Browser Console (Ctrl+Shift+j) and see if anything seems to reliably appear in the logging there, right at the moment when this bug reproduces?

(I think we've hit issues like this in the past where there's a JS exception that's thrown and never caught for some unforeseen edge case as we're setting up the print dialog, and that can cause things to get stuck with no CPU usage or progress being made like this. Usually that results in something being logged to the browser console, I think.)

Comment 12

[Tony Davis]

Before I try to reproduce this, I would like to ask and "internals" question about the Print Preview:
Does it actually need to API interface with a physically available/running printer to generate a preview? The reason I ask, is that I have seen the Preview come up, and display the printer list UI, even when that UI shows the disconnected printer as the first one in the list, as if it was the default one.
If it needs the paper size to create a preview, I beleive these would already be available in the CONFIG list for any of the previously used printers, so you code SHOULD (in theory) be able to create a sensible/viable preview, then allow the user to select the actual (connected) printer needed for use in the active session. If the wrong printer is chosen, I would have thought that the Spooler and O/S would handle that in the normal way (cannot connect error).

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Tony Davis from comment #12)

Does it actually need to API interface with a physically available/running printer to generate a preview?
If it needs the paper size to create a preview, [...]

I'm a little fuzzy on the details (I think AlaskanEmily & emilio & jwatt have a clearer concept of the process here), but I think the following is correct and roughly answers what you've asked:

1. To usefully display the print dialog, we do need to have information about the currently-selected printer (what page sizes / duplex options / color-settings does it use, how close to the edges can it print, etc.) This is necessary for an accurate preview, but it's also necessary just to be sure that the default values we're presenting for all of these print-settings options are coherent & match reality, so that something sensible/possible will happen if the user goes ahead and clicks "print".
2. The dialog starts out with whatever printer is stored in the print_printer pref (which is the most-recently-used print target).
3. When the dialog appears, we ask the OS for information about all print destinations, and particularly the one that's selected-by-default (i.e. the one stored in the print_printer pref), so that we have enough information to render a preview and show a valid set of options, per (1).

I think typically the OS itself will have enough information (available locally) to answer us, regardless of whether the printer is connected. (And if you proceed with a print operation and the printer turns out to be disconnected, the OS has the ability to either queue or fail the print job.)

So: in cases where the print dialog just hangs forever, as it seems to be doing in the profile that you captured, it shouldn't generally "just" be because the printer is disconnected. It's likely that something more than that is unexpectedly going wrong, which could perhaps involve some JS exception being thrown (which would show up in the Browser Console per comment 11). Or it could involve the OS taking longer than expected to provide some answer, perhaps.

Comment 14

[Daniel Holbert [:dholbert]]

Update: I got some windows machines together and tried to recreate the reporter's setup, and I was able to do so.

Basic setup:
I've got a printer connected via USB to my first Windows 11 machine (which I'll call the "server machine"), shared on the network (via the Printer Properties dialog "Sharing" tab). I left the "Render print jobs on client computers" checked (the default). I then opened the Windows file browser and went to the "Network" section on both machines and clicked through to allow sharing on my current network. Then, on the second Windows 11 machine (the "client machine") in the file browser "Network" section, I clicked the icon for the server machine, authenticated, and was able to see the shared printer. I right-clicked it and chose "connect". This made it appear in my list of available printers. Then I used that printer from Firefox so that it'd be selected as print_printer. Then, I suspended the server machine and rebooted the client machine.

When the client machine came back from reboot (while the server machine was suspended), the first attempt to print from Firefox did indeed reproduce this bug.

Profile of the bug for me: https://share.firefox.dev/3VndCXz

A few notes:
(1) There's nothing interesting in the browser console. So this isn't just an uncaught-JS-exception sort of issue.
(2) For me, at least the print preview dialog does finish hanging and render just fine after about 30 seconds, at least in this case. (I'm not sure if it's always the case; in the reporter's "bad" performance profile -- second one in comment 9 -- the profile doesn't extend for long enough to tell. It looks like that profile ends right about 30 seconds after the print dialog appeared.)
(3) After the print preview dialog eventually finishes hanging and renders properly, it remains fine (no hangs/delays), including after I quit and reopen Firefox.
(4) However, after I reboot the machine, my first attempt at opening the print dialog will trigger this issue again.

Comment 15

[Daniel Holbert [:dholbert]]

Interestingly, Microsoft Edge seems to hit roughly the same bug, but it's worse when I hit it there.

They show the print-settings UI (Printer, Copies, Portrait|Landscape, etc), but you can't interact with it, and you can't even cancel out of the print dialog. The whole app is locked up.

So I think this is a case where some underlying Windows API is taking a while to look up an answer about printer settings, and it takes tens of seconds to time out, and in the meanwhile apps are left waiting without any information. In Edge's case, this blocks the main thread and locks up the UI. In Firefox's case, it's on a background thread and you have the opportunity to cancel out.

Comment 16

[Daniel Holbert [:dholbert]]

(And at some point -- not necessarily right away but soon -- Windows seems to save the fact that it gave up; and from that point on, apps get a snappy response from the underlying API when they request the printer information.)

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #15)

Interestingly, Microsoft Edge seems to hit roughly the same bug, but it's worse when I hit it there.

They show the print-settings UI (Printer, Copies, Portrait|Landscape, etc), but you can't interact with it, and you can't even cancel out of the print dialog. The whole app is locked up.

Actually, they don't even do this^ part (they don't show any settings) initially. After a reboot, their print dialog is blank for ~30-45 seconds, and then it populates that info and spins again for 30-45 seconds, and then finally it renders a preview (after ~90 seconds). I just captured a screencast intending to attach it here, but unfortunately it's ~200MB so it's too big for Bugzilla's upload limits. :)

So it looks like this might be more of a Windows bug than a Firefox bug. It's something that we could conceivably be more-graceful about (e.g. maybe we could let you intervene and select a different printer). But in the meantime, our behavior is more graceful than Microsoft's own browser, since at least we're not locking up the whole app, and we do let you cancel out of the print dialog.

Tony, could you confirm that you're seeing the same results on your end? (e.g. check if Edge is having the same trouble as Firefox here if its most recent print job was to the printer in question, and then a reboot with the server machine switched off/unreachable at that point)? Thanks!

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #17)

Interestingly, Microsoft Edge seems to hit roughly the same bug, but it's worse when I hit it there.
I just captured a screencast intending to attach it here, but unfortunately it's ~200MB so it's too big for Bugzilla's upload limits. :)

Here's the screencast on YouTube: https://youtu.be/3y7KhhWJP_Q

Comment 19

[Tony Davis]

Hi Daniel, many thanks for your testing work on this. I beleive I have seen that 90 second hang, when trying a disconnected printer, during my recent testing attempts. However, my initial problem that prompted me reporting a bug MIGHT still be a JS intervention issue. The reason I say that, is the initial issue was created using the Amazon return label function, that I believe IS JS controlled, and puts a "mini-PDF" like label in the middle of the screen, and when you select "print it now", the hang is constant (I left it well over 10 minutes before giving up and looking into it).

It is possible that I did NOT set the printer on the TONY-PCW7 back as the default printer before discovering tha fact that the print-printer pref value is important. I manually changed the print-printer value it to get the label I needed, before realising that changing the default printer to the correct connected one seems to do that.

I will try the Edge with printing, to see if I can get a hang like you have found. Give me a couple of days. Thanks

Comment 20

[Daniel Holbert [:dholbert]]

(In reply to Tony Davis from comment #19)

the initial issue was created using the Amazon return label function, that I believe IS JS controlled, and puts a "mini-PDF" like label in the middle of the screen, and when you select "print it now", the hang is constant (I left it well over 10 minutes before giving up and looking into it).

Thanks for those details. A 10-minute hang is definitely concerning and sounds distinct from the non-Firefox-specific Windows issue that I've been observing when testing this.

If you can reproduce that again, and can provide any further details on that (e.g. does that hang seem to require a disconnected printer vs. be unrelated; is it reliably longer than the other hang described above, and does anything interesting appear in Ctrl+Shift+J browser console when the issue happens), that'd be really helpful.

Comment 21

[Daniel Holbert [:dholbert]]

Just a reminder - per comment 20, any additional info here would be helpful here, if you can still reproduce ~10 minute hangs or Firefox-specific hangs (note that it might only affect the first app that tries to print after a reboot, since Windows tries to do the slow thing and then caches the response, or something like that).

Otherwise I suggest we close this as not-a-Firefox-bug, per above notes about other browsers hitting the same Windows issue.

Comment 22

[Tony Davis]

I have done more testing, and it seems that since the systems I am working with had had several O/S updates, and the browsers have now been updated too, the slight delays seen in the preview first time through the spooler API calls seem much shorter (after reboots etc, or printer turned off testing, and disconnected/wrong default printer test). Maybe one of the security updates improved spooler interface timeouts or performance.
My thinking now is that the loop greater than 10 minutes that I saw whan I raised this bug report, was due to the Amazon Label printing JS script getting some sort of issue when calling the print preview, when the printer default was set to the offline printer.

Now that I am armed with the Profiler Performance utility, that I will keep on the Laptop FF that is in daily use, when I get another issue with the Print Preview, I can get another diagnostic file, and either add it to this, or to another new bug report if this gets closed.

It may take a month or more before I hit this issue again, so if you need to close it, I am happy with that, whatever your standard process dictates.

In the meantime, many thanks for your efforts in trying to reproduce this, it is much appreciated. Regards, Tony.

Comment 23

[Daniel Holbert [:dholbert]]

Thanks for the note!

(In reply to Tony Davis from comment #22)

My thinking now is that the loop greater than 10 minutes that I saw whan I raised this bug report, was due to the Amazon Label printing JS script getting some sort of issue when calling the print preview, when the printer default was set to the offline printer.

Just to clarify, when I mentioned a possible JS Exception causing a hang in comment 11, I was talking about Firefox's own internal JS code that runs our UI, rather than e.g. Amazon's JS code. (There shouldn't really be a way for a site's JS to cause the print preview dialog to hang, particularly in a printer-specific way -- but it is possible for the Firefox-internal JS code to trip over some unforeseen edge case where it sets up the dialog and then chokes, manifesting in what looks like a hang.)

Anyway: I'm glad that 10 minute issue was a one-off, so far. So: I'm going to close this out, since that original issue hasn't recurred so far (and the variant that did recur seems to be non-Firefox-specific, as far as I can tell). If you do end up reproducing the long hang again, though, please do reopen. Thanks!

(side note: I wonder if the long hang might be the same Windows issue. I never saw anything longer than a minute or so, but I wonder if Windows is intentionally limiting the hang to that long, or if it's just an arbitrary amount of time due to a dependency on some nondeterministic event/signalling.)