Bug 616774 - "Volume is busy" window should have a title
"Volume is busy" window should have a title
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nautilus (Show other bugs)
6.0
All Linux
low Severity low
: rc
: ---
Assigned To: Tomáš Bžatek
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-21 08:02 EDT by Lubos Kocman
Modified: 2015-03-03 17:51 EST (History)
7 users (show)

See Also:
Fixed In Version: nautilus-2.28.4-16.el6
Doc Type: Bug Fix
Doc Text:
Cause: The "Volume is busy" dialog spawned from desktop was not connected to any window. Consequence: An "Untitled window" item appeared on the taskbar. Fix: Dialog has been set transient for the desktop window and this automatically removes taskbar item. Result: No item is displayed on the taskbar anymore and the dialog is properly connected with the desktop window. Should user lose this window, clicking on the desktop window (i.e. background) will make the dialog focused again.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-24 06:56:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot (27.94 KB, image/png)
2010-07-21 08:02 EDT, Lubos Kocman
no flags Details
nautilus-2.28.4-gtk-mount-operation-parent.patch (6.96 KB, patch)
2011-01-04 05:28 EST, Tomáš Bžatek
no flags Details | Diff
Screenshot After Bugfix (676.17 KB, image/png)
2011-01-11 11:44 EST, Michael Boisvert
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1203 normal SHIPPED_LIVE nautilus bug fix update 2011-08-24 06:55:53 EDT

  None (edit)
Description Lubos Kocman 2010-07-21 08:02:32 EDT
Created attachment 433394 [details]
Screenshot

Description of problem:

Dialog window that is informing you that some volume is busy is without title. The window is labelled as "Untitled window" in gnome-panel.

Version-Release number of selected component (if applicable):

gvfs-1.4.3-9.el6.x86_64

How reproducible:


Steps to Reproduce:
1. insert some dvd
2. make it being used by some process (cd /media/...)
3. unmount the media using right click -> Eject
  
Actual results:

Dialog window without title

Expected results:

Dialog window should have a title like "Volume is busy". So it can be easily found via gnome-panel.

Additional info:
Comment 1 Lubos Kocman 2011-01-04 03:44:55 EST
NOTE: Just for clarification you have to use device icon on the desktop.
Comment 2 Tomáš Bžatek 2011-01-04 04:44:08 EST
This is actually a Nautilus bug.
Comment 3 Tomáš Bžatek 2011-01-04 05:28:11 EST
Created attachment 471630 [details]
nautilus-2.28.4-gtk-mount-operation-parent.patch

Proposed patch, passing a proper GtkMountOperation instance further down the stream. Basically we set desktop window (hidden) as a parent window for GtkMountOperation, which will also hide taskbar item.
Comment 8 Michael Boisvert 2011-01-11 11:39:17 EST
I was able to see both the problem and the proposed fix successfully while testing in RHEL6.0.

I don't know if the fix actually solves the problem. It hides the untitled window from the taskbar and the dialog window still does not have a title. Lubos, does this fix satisfy what you're looking for?
Comment 9 Michael Boisvert 2011-01-11 11:44:24 EST
Created attachment 472846 [details]
Screenshot After Bugfix

The dialog window is not on the taskbar and still has no title.
Comment 10 Tomáš Bžatek 2011-01-12 05:52:58 EST
(In reply to comment #8)
> I don't know if the fix actually solves the problem. It hides the untitled
> window from the taskbar and the dialog window still does not have a title.

That is correct, not every window needs to have a title. In modern desktop title for some dialogs is not drawn at all.
E.g. http://git.gnome.org/browse/gtk+/commit/?id=66745a993d2d017954e2cde30e92c806b6cde449

Also please don't set bug component to crazy values.
Comment 11 Michael Boisvert 2011-01-17 15:27:28 EST
Prior to installing the new package, the window would steal focus and could not be covered up. It appears that the fix has broken this feature. Also, why would a warning window not require a title?
Comment 12 Florian Nadge 2011-01-19 12:20:33 EST
Please be so kind and add a few key words to the technical note of this
bugzilla entry using the following structure:

Cause:

Consequence:

Fix:

Result:


For details, see:
https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes

Thanks
Comment 13 Florian Nadge 2011-01-19 12:20:33 EST
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause:

Consequence:

Fix:

Result:
Comment 14 Michael Boisvert 2011-01-19 15:02:27 EST
The fix was worse than the original behavior. It caused the untitled window to not keep focus and could become easily lost. I suggest dropping this advisory and re-evaluate a better solution.
Comment 16 Tomáš Bžatek 2011-01-20 05:33:05 EST
(In reply to comment #11)
> Prior to installing the new package, the window would steal focus and could not
> be covered up. It appears that the fix has broken this feature.
It still steals focus for me - when you right click a desktop icon, you automatically make desktop focused.

> Also, why would a warning window not require a title?
Talk to our designers. Windows requiring a title is a dogma which is no longer valid in modern desktop. Also, why would we need to repeat a text that is displayed in more emphasised form in the window?

(In reply to comment #14)
> The fix was worse than the original behavior. It caused the untitled window to
> not keep focus and could become easily lost. I suggest dropping this advisory
> and re-evaluate a better solution.
Let me explain what's happening with the patch. Basically we made the behaviour consistent with the case where a dialog is spawned from a Nautilus window. Such dialogs are made transient to their parent windows, "owners". So that when you make a Nautilus window active, associated dialogs stay on top of it. But are associated only to that window. Different windows can have their own set of transient dialogs. Desktop is essentially just another window. This patch properly sets parent window to desktop. If you need to reach a dialog that is associated to desktop, just click the desktop and transient dialogs will pop up.

Also, by setting dialog transience, window manager will hide a taskbar item since now the window belongs to some parent.


CCing Mo to act as a judge from design point of view :-)
Comment 19 Máirín Duffy 2011-01-20 13:15:34 EST
Hi Tomáš & Lucas,

I'm not sure if the referenced GTK+ commit in comment 10 is relevant (that may have been a fix because the dialog was inheriting an inappropriate title or something since one wasn't explicitly set). But Tomáš is right, alert windows according to the GNOME HIG are not supposed to have window titles:

"Alert windows have no titles, as the title would usually unnecessarily duplicate the alert's primary text. This way, users can read and respond to alerts more quickly as there is less visual noise and confounding text."

The original bug was actually that the alert window had an entry in the panel widget, e.g.,

"An alert should not appear in the panel window list unless it is, or may be, the only window shown by an application. For example, an appointment reminder alert may be shown after the main calendar application window has been closed."

One thing to note here,

"Alerts do not appear in the system window list. Consequently, take care to ensure that alerts stay above their parent window. Otherwise, users will be likely to lose the alert and find your application unresponsive for no apparent reason. Modal windows should always stay above the window(s) they block."

I have hit the above issue with some GTK+ apps, although generally Nautilus tends to be good about this sort of thing. 

I do believe in the screenshots attached that the titleness alert window looks a bit odder than usual because of the choice of GTK+ theme.

The part of the HIG I'm referencing is here:
http://library.gnome.org/devel/hig-book/2.32/windows-alert.html.en

Hope this helps!
Comment 20 Tomáš Bžatek 2011-01-28 03:33:12 EST
Thanks for your point of view Mo, you're right, the referenced commit might not be 100% relevant. I've talked to Cosimo yesterday and we agreed to push the patch as proposed, but only for the classic Gnome 2 desktop. For gnome-shell/mutter, the dialogs such like this would need to be reviewed to play nicely with the shell's notification system. But that's out of scope of this bug.
Comment 21 Tomáš Bžatek 2011-01-28 03:54:10 EST
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,7 +1,7 @@
-Cause:
+Cause: The "Volume is busy" dialog spawned from desktop was not connected to any window.
 
-Consequence:
+Consequence: An "Untitled window" item appeared on the taskbar.
 
-Fix:
+Fix: Dialog has been set transient for the desktop window and this automatically removes taskbar item.
 
-Result:+Result: No item is displayed on the taskbar anymore and the dialog is properly connected with the desktop window. Should user lose this window, clicking on the desktop window (i.e. background) will make the dialog focused again.
Comment 29 errata-xmlrpc 2011-08-24 06:56:00 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1203.html

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