RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1056129 - Print dialog can show alarming 'May not be connected' message in error
Summary: Print dialog can show alarming 'May not be connected' message in error
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gtk2
Version: 6.5
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Benjamin Otte
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-21 14:44 UTC by Dan Astoorian
Modified: 2017-12-06 12:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 529364
Environment:
Last Closed: 2017-12-06 12:14:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Dan Astoorian 2014-01-21 14:44:22 UTC
+++ This bug was initially created as a clone of Bug #529364 +++

Description of problem:
The same symptom as described in Bug #529364 in Fedora 10 (spurious "may not be connected" messages being briefly displayed when a job has been submitted to a CUPS print queue) is manifesting itself on our systems since updating from RHEL 6.4 to RHEL 6.5.

I have not determined whether the cause is the same (i.e., whether this is a regression in gtk2 which recently made its way into Enterprise Linux with Update 6).

Our CUPS printers are lpd:// print queues, in case that's relevant or useful in reproducing the problem.

Description from the original bug:

The print dialog shows the current state of each queue, which is very useful.  However, when this is performed for a busy queue, the snapshot at the point where a new job has just begun can look alarming.

The reason is that the job backend has started to connect to the device, so it sets the 'connecting-to-device' state reason for the queue.  A moment later it will hopefully remove that state reason.

Unfortunately the GTK+ print dialog interprets 'connecting-to-device' as a reason to display a printer-error icon and a "may not be connected" message.

Really it should not display this message unless that state reason has been there for 'a while'.  For example, system-config-printer-applet waits for 60 seconds and only shows a warning if the connecting-to-device state reason has been continuously present.

The GTK+ print dialog doesn't have the luxury of waiting that long, but perhaps it should wait until it has seen it in two successive polls or something?

Version-Release number of selected component (if applicable):
gtk2-2.20.1-4.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Send a print job to a CUPS print queue
2.Mouse over the printer icon in the notification area
  
Actual results:
"may not be connected" message can flash on screen for a few seconds.

--- Additional comment from Matthias Clasen on 2009-10-16 08:26:51 EDT ---

Yes, that makes sense to me. I'll ask Marek to take a look at this.

--- Additional comment from Marek Kašík on 2009-10-19 11:24:48 EDT ---

Hi,

the "Printer '%s' may not be connected." message is taken from system-config-printer. The error icon is showed because there is no suffix (warning or report) and according to IPP's RFC (4.4.12) it should be treated as an error.
The problem of successive polls is that 2 are not enough and I can imagine that 5 will not be enough in some cases (in Fedora 10, 11).

One solution is to set the number of successive polls with "connecting-to-device" to a very high number (for example 10 for Fedora 10, 11 and 150 for Fedora 12).

Second solution could be an ignoring of this printer state reason.

Third solution can be showing of a text like "Connecting to printer '%s'." without any emblem on printer's icon.

The first one is a heuristic which can work, the second is not very nice and the third seems acceptable for me (user is informed and happy :) ).

Which solution do you prefer (I prefer the third one)?

gtk2 do its own connection test for remote printers since Fedora 12. Do you think that it is enough to not indicate the "connecting-to-device" reason when the test is successful?

Regards

Marek

--- Additional comment from Tim Waugh on 2009-10-20 06:55:36 EDT ---

Yes, third suggestion sounds best.(In reply to comment #2)

> gtk2 do its own connection test for remote printers since Fedora 12. Do you
> think that it is enough to not indicate the "connecting-to-device" reason when
> the test is successful?

If you mean that connecting-to-device shouldn't be regarded as an error state reason, yes I think that's best.

--- Additional comment from Marek Kašík on 2009-10-21 09:23:54 EDT ---

Hi,

when diving more into the problem I see that "printer-state-message" already sets a message describing actual situation for the "connecting-to-device" reason.
It shows these messages: "Printer is now online.", "Copying print data...", "Waiting for job to complete..." and "Connecting to printer...".

So the second solution seems the best for me now.

Marek

Btw, I found out that the connection test is performed only when getting PPD for actual printer, so we doesn't have this information for all printers.

--- Additional comment from Fedora Update System on 2009-10-28 12:46:35 EDT ---

gtk2-2.14.7-9.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/gtk2-2.14.7-9.fc10

--- Additional comment from Fedora Update System on 2009-11-10 22:04:29 EST ---

gtk2-2.18.3-21.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gtk2-2.18.3-21.fc12

--- Additional comment from Fedora Update System on 2009-11-11 19:54:23 EST ---

gtk2-2.18.3-21.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gtk2'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11415

--- Additional comment from Fedora Update System on 2009-11-16 02:25:09 EST ---

gtk2-2.18.3-21.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from Fedora Update System on 2009-11-16 02:33:22 EST ---

gtk2-2.14.7-9.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 3 Jan Kurik 2017-12-06 12:14:02 UTC
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/


Note You need to log in before you can comment on or make changes to this bug.