focus does not return to desktop after opening and closing a file on it if anther window is open

Bug #268963 reported by pete
6
Affects Status Importance Assigned to Milestone
metacity (Ubuntu)
Incomplete
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: nautilus

Steps to reproduce:
- open a folder in nautilus and select a file
- with that window to the side, open a file on the desktop by double clicking
- close the open file
- hit delete

One would expect that the file on the desktop would be deleted, however the selected file in the nautilus window is deleted as that window has been given focus.

This is particularly confusing on themes such as Clearlooks that do not provide a clear distinction on selected files in the active versus inactive window.

Gnome 2.22.3 on Ubuntu 8.04 (Hardy)

Revision history for this message
Sebastien Bacher (seb128) wrote :

thank you for your bug report, do you use the desktop effects option?

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
pete (petehere) wrote :

thanks for your response, no I don't

Revision history for this message
Sebastien Bacher (seb128) wrote :

that's not a nautilus bug but the wm giving the focus to open dialog which is likely what the user want to use

Changed in nautilus:
status: Incomplete → Invalid
Revision history for this message
pete (petehere) wrote :

I disagree that it's more likely what the user wants.

The focus is returned to the top most window (z order) rather than the window that last had focus (desktop).

Take this use case:
1. user opens a file on the desktop to determine it's contents
2. they verify that the file is no longer needed and close the window
3. they hit delete to delete the file
4. instead some other random action occurs depending on what window is on top

In my case this caused data loss when I used shift-delete as I was confident that I no longer needed an empty directory on my desktop, and instead deleted a directory of files that I had been earlier working on in an open nautilus window.

Perhaps this is a bug with metacity taking focus and z-order to be the same thing.

Revision history for this message
pete (petehere) wrote :

should read "focus history and z-order"

Revision history for this message
pete (petehere) wrote :

Changing package to metacity and setting status to incomplete as a fix hasn't been offered

Changed in nautilus:
status: Invalid → Incomplete
Revision history for this message
sceo (christopher-j-wells) wrote :

I'm seeing this behavior but only after upgrading to Ibex (or potentially messing with my compiz settings?). I am using compiz. Basically, the "desktop" isn't allowed to have focus or something. That is, let's say I'm in pidgin watching a chat room. That's the active window. I then click on an icon on my desktop, and press the delete key. The delete keypress goes into the pidgin window (not deleting my file), because when I click on something on the desktop, the pidgin window doesn't lose focus.

Similarly, I used to be able to rotate my cube by CTRL-ALT-LClick-Drag, which I can still do but only if my mouse pointer is over a window. The desktop no longer "counts" (and instead it just starts drawing a highlight box on my desktop).

So, how come the desktop isn't an application that can get focus any more?

Revision history for this message
sceo (christopher-j-wells) wrote :

I switched to metacity and it doesn't not show this behavior (ergo, my issue must have been with compiz, so not really applicable to this bug). However, I switched back to compiz after doing that and everything worked fine, even across reboots. So just something weird in compiz that, somehow, switching to metacity and back again fixed.

Revision history for this message
John (john-m-lang) wrote :

I'm seeing this since Intrepid with Metacity. Desktop effects are disabled. I have a dual-monitor ATi setup. I am using the Clearlooks theme.

I will be working in an app and select a file on my desktop to rename or delete using keyboard shortcuts and the operation is performed in the app instead. I have not discovered what triggers this behavior.

I noticed that when this happens, the Window Decorations of the last app used stays active even when selecting a file on the desktop. If I have multiple windows open and change the focus between them, the desktop is not granted focus.

One workaround I've found to give the desktop focus is to use the Show Desktop applet in the panel.

Revision history for this message
Sebastien Bacher (seb128) wrote :

could you try if that's still an issue in jaunty?

Revision history for this message
Andreas B. (andreas-b123) wrote :

Yes, it's still a Bug in 9.04, but it has NOTHING to do with metacity!

I use Compiz witz Emerald. Exact the same problem, but only since ubuntu 9.04!

Andreas

Revision history for this message
John (john-m-lang) wrote :

Yes, I am still experiencing this bug with Jaunty with Metacity and Desktop Effects disabled.

My guess is that this bug should be upstreamed but I don't know what the relevant upstream project would be...

Revision history for this message
Oded Arbel (oded-geek) wrote :

Metacity always selects an active window when another window is closed.

The problem with the desktop effect enabled is another issue - bug #457139 - and in that, the behavior when closing a window is somewhat different. See that bug report for details.

Revision history for this message
pete (petehere) wrote :

Yep, I guess this is the behaviour that I was reporting the initial bug against. If I open a file on the desktop and then close that file, I (personally) would expect focus to be given back to the desktop.

The problem is that focus is given to the highest (z-order) window, rather than the most recent window (focus history).

Incidentally, what would the behaviour be for a window that was "always-on-bottom"?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.