GNOME Bugzilla – Bug 310170
Dialog not kept above when it should
Last modified: 2008-09-06 19:10:34 UTC
From bug 163973: Use "connect to server" to create a new server icon (I test with webdav). Drag a file to it. When it asks for a password, wait. The copy/move progress window will appear on top of the password dialog. This tends to disturb people who are just trying to remember their password. I've set the _KEEP_ABOVE flag on the password dialog, but the copy progress dialog (which hasn't it set) obscures it if the latter pops up afterwards. I'm on metacity 2.8.8.
Created attachment 49053 [details] xprop output of to-be-kept above window
Created attachment 49054 [details] xprop output of window which obscured KEEP_ABOVE window
Don't set ABOVE just make sure the transient relationships are represented properly. The password dialog in this case should be a transient child of the copy progress dialog, so transient_for needs to be set to the window ID of the copy progress dialog. If you set STATE_ABOVE on a window the rest of the windows in that group are also going to be promoted to the above layer.
Rob: Thanks for the explanation. The EWMH spec [1] suggests: " To obtain good interoperability between different Desktop Environments, the following layered stacking order is recommended, from the bottom: * windows of type _NET_WM_TYPE_DESKTOP * windows having state _NET_WM_STATE_BELOW * windows not belonging in any other layer * windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE *" The point is that IMHO we have at the moment no means to make a good guess the transiency parent window, since the invocation authentication dialog invocation is done through the VFS activation daemon, and the API doesn't have any window parameter we could use as transiency target. [1] http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER
The promotion of items in the same group as a STATE_ABOVE, DOCK, or FULLSCREEN item is pretty important to ensure that these applications work correctly, such as dialogs launched from fullscreen windows (clearly, these dialogs can't set the fullscreen hint). There's another bug in here somewhere about the full reasons why we have to do it that way. Sounds like an VFS API bug. If it's going to be making popup windows, it is absolutely crucial for window stacking that it set the transient hints correctly. Making this dialog STATE_ABOVE is a crude workaround that won't work for a number of situations, such as a panel applet doing a gnome VFS-operation, or a fullscreen window doing a gnome VFS operation similar to what you're doing. For the FULLSCREEN case, there is no hint you could set to try to work around it.
Rob is right on this, the API just has to have a transient parent argument. There's no other way to fix it for all cases.
Thanks for your explanations.
Updating to 2.14, milestoning to 2.16 because the API is still not able to deal with transiency.
gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome. If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs. @Bugzilla mail recipients: query for gnome-vfs-mass-close to get rid of these notification emails all together. General further information: http://en.wikipedia.org/wiki/GVFS Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html