After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 586211 - Printing dialog with a CUPS printer connected to a switched off remote PC hangs for ~30s
Printing dialog with a CUPS printer connected to a switched off remote PC han...
Status: RESOLVED DUPLICATE of bug 586207
Product: gtk+
Classification: Platform
Component: Printing
2.17.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-06-18 07:59 UTC by Matteo Settenvini
Modified: 2009-06-18 08:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28



Description Matteo Settenvini 2009-06-18 07:59:40 UTC
Please describe the problem:
This certainly happens in Ubuntu Intrepid, Jaunty and Karmic, but on Launchpad they say it's probably an upstream issue as well. So it's more than a year this bug is out in the wild for me.

I've got a printer connected to a remote machine; on certain times that machine is powered off for various reasons.

While I can queue jobs manually from the command line (for example, "lpr output.pdf"), if I try to print from evince, epiphany or any other program using the default gtk+ printing dialog, and I select the shared printer, the "Print" button is disabled, and thus I cannot queue any job.

The funny part I noticed fairly recently, is that I can double-click on the printer name in the GtkListView, and printing starts even if the "Print" button is not enabled; but probably this is *another* bug (and unintended behaviour, too).

However, the printing dialog freezes and doesn't redraw and is irresponsive for almost 30 seconds, probably because some polling is being done, making the user believe the application completely hung.

I consider this a regression and a bug (not a feature). In my office, for example, there may be cases when the printing server is down, however twenty-thirty people want to queue jobs remotely, and come and retire their sheets only an hour later.

They don't care if the printing server is up or not, and that is the benefit of having a local spooling server on a remote PC: as soon as the machine is up again all the jobs in queue get printed.

They just want to send a job and forget about it. Especially if they're printing orders from the sales department, and the sheets get collected only twice per day from the archivist in another room ten km off.

Not being able to spool jobs for a unreachable printer if you're roaming with your laptop, or if the server is down, is quite a drawback in my opinion.

Steps to reproduce:
1. Set up a shared CUPS printer on computer A on the LAN
2. Make sure computer B sees the shared printer; in Ubuntu for example it does show in the "Printing" dialog under "System" -> "Administration". You may need to add it manually as a remote printer.
3. Shutdown computer A
4. Fire up Evince (or any other gtk+ app), and select "Print" from the file menu


Actual results:
a) the dialog comes up, but is empty for about 30s, doesn't get redrawn, and the whole app seems to hang
b) the printer on PC A is in the list and you can select it, but the "Print" button is not active.

Expected results:
a) The dialog is displayed instantly and works well
b) I can queue jobs also on the remote printer, even if the other PC is shut down

Does this happen every time?
Oh yes.

Other information:
Comment 1 Matteo Settenvini 2009-06-18 08:06:16 UTC
Previously reported also on launchpad at:
https://bugs.edge.launchpad.net/gtk/+bug/254030

There's also a screenshot there.
Comment 2 Baptiste Mille-Mathias 2009-06-18 08:22:27 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


*** This bug has been marked as a duplicate of 586207 ***