New windows steal focus

Is there anything happening with this bug? It is happening to me as well and is extremely annoying.

Hello, thank you for taking the time to report this issue. Please correct me if my interpretation of your issue is wrong. If you initiate a new window from 'somewhere', and then change your focus to something else before that new window appears, the new window will steal the focus?

As a slightly different scenario, let's consider opening a new window from a program (like eog from nautilus). Which window do you expect to have focus?

Moving this to gnome-desktop away from compiz, as this issue is more general than compiz.

By, the way, just to be sure, could you please test this behavior with compiz turned off? I am pretty sure the same problem will occur, but this is just to be sure.

WeatherGod: here's what is happening for me with Compiz activated:
 - I click on Firefox icon to launch it.
 - While Firefox is loading, I click on a terminal and start typing text.
 - Now, the Firefox window finally appears in front of the terminal, but the focus is still on the terminal. That means that I can continue typing text into the terminal, but the Firefox window is hiding the terminal window.

Using plain metacity, the behaviour is even worse: when the Firefox window appears, it steals focus from the terminal, which means that it appears in front of the terminal AND new key strokes appear in the Firefox window.

I think that Compiz behaviour is almost perfect. The only problem is that the newly opened Firefox window should appear behind the terminal window, and the Firefox entry in the window list should be blinking to indicate that it's now ready to use.

As for your second question, if I open an EOG window from Nautilus, I expect the EOG window to get focus except if I interact with the Nautilus window before the EOG window appears.

I have juste tested this behaviour on another computer, with Ubuntu Jaunty (compiz 0.8.2), and, on this computer, compiz is behaving correctly: the new window appears behind the one with which I'm interacting ! However, the problem is still the same with Metacity.

Does that mean that there was a regression between compiz 0.8.2 and 0.8.4 ?

Julien, thank you for the very clear report of your issue and your expectations. I agree that the behavior you expect should be the default behavior.

As for the difference between 0.8.2 and 0.8.4, I would first see what are the differences in the configurations between the two machines.

I've checked all the options I could think of in gconf on both computers and couldn't see any difference. Please, could you tell me which keys I should check ?

gnome-desktop is the about GNOME dialog and a library, not a bug there

Now, I have re-tested this behaviour with 3 computers, all updated to Lucid, and all 3 suffer from this bug.

I do have this problem, too. Ubuntu 10.04, Compiz 0.8.4.

This problem is mentioned in several other bug reports about more specific cases (usually the Update Manager), see below.

But it's a general problem. Mind the security impact!

Synaptic steals focus when minimized or when behind other windows
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/54300

Configuration Dialogs should not steal focus during updates
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/373974

'Downloading package information' and 'building dependency tree' progress dialogs request focus too often
https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/35876

Dialogs of background applications pop up in the foreground
https://bugs.launchpad.net/metacity/+bug/67476

Child Windows [of Synaptic/update manager] should remain in the same desktop as the parent window
https://bugs.launchpad.net/hundredpapercuts/+bug/391479

Still in Ubuntu 13.10. Very annoying.
Compiz 1:0.9.10+13.10.20131011-0ubuntu1

Still happening in Ubuntu 14.04. I'm on Sublime, so I open an app like Chrome and while this app is loading, I'm go back to Sublime and continue to write. So, after a while, Chrome loads, steal the focus and before my brains know it, I'm typing the Sublime text on Chrome, leading to a mess :P

This is very annoying because I open and close apps (or they open dialogs automatically) very often, as well I write very often, and because this random focus steal, I always have to check if I'm writting on the right place, like a paranoid.

I'm already developed an ctrl+s like syndrome (you know, the one that you write few words, save, then write more two or three words, save again and so on). I have to write some words, so I stop and check the focus, type more few words, check again, type more few words, ... This is really annoying for all those who have fast fingers and who are hardcore keyboard users.

Thank you for taking the time to report this bug. The compiz program that we currently use in Ubuntu is a C++ re-write of the original compiz and was announced the 4th July 2010. Therefore, the bugs that were reported before that date, will be marked as "Won't Fix" as they probably exist in the original program which is not stored in launchpad. (The last LTS that used the old compiz is the 10.04 which is not supported anymore).

This bug/feature still affects current compiz (I am on 15.04 and I just reproduced it. Should I open a completely new bug?

Thanks for the reply, could you just change the status to Confirmed and tell us the steps to reproduce it?

Also, which is your desktop environment? Is it Unity?

Yes, Unity on 15.04. I do not have priviledges to revert a wont fix, somebody else have to do that.

Steps to reproduce:
1. Open a lightweight application like gedit.
2. Open an application that starts for a long time (GnuCash on my computer with 7 years of accouting) - may be different on your macihne
3. Before the application from step 2 initializes, switch to application from step 1 and start using it (i.e. typing in gedit)

What happens:
When the application from step 2 opens, it steals focus, goes to the forground and starts receiving input that up to that point was receiving application from step 3

What should happen:
The application from step 2 should open in the background and set its status to alert (that blue triangle in the launcher in Unity).

I see, thank you for the workaround, I change the status to Confirmed and we ll look at it at a convenient time. :)

(It is not a workaround per se- that setting affects focus in various ways that are not always desired, so I myself rather set it to low - this problem has been less severe since I bought an SSD disk since most applications now start instantenosly. However, on a rotation harddrive, this used to drive me crazy)

As part of the big bug review for 16.04 LTS, I have tested this on 15.10 and the bug is still there.

Additional methods to reproduce:
* Android Studio every time a build completes. I've typed bash commands into my build.gradle so many times.
* Cancel/Skip/Replace popup during a background file copy.
* New Pidgin IM windows.

The bug is still in 16.04. Very unsecure when typing passwords.

FWIW The GNOME mutter project contains a detailed explanation about
how to handle window focus to never have "focus stealing":
https://github.com/GNOME/mutter/blob/master/doc/how-to-get-focus-right.txt

Quote follows:

Also, sometimes a new window will be mapped (e.g. unminimizing a
window or launching a new application). Most users want to interact
with new windows right away, so these should typically be focused.
This does conflict with the invariants for sloppy and mouse focus
modes, so this wouldn't be true for a strict-pointer-focus mode. For
all other modes (non-strict-pointer-focus modes), there are only two
cases in which a new window shouldn't be focused:

  1) If the window takes a while to launch and the user starts
     interacting with a different application, the new window should
     not take focus.
  2) If the window that will appear was not launched by the user
     (error dialogs, instant messaging windows, etc.), then the window
     should not take focus when it appears.

To handle these cases, Metacity compares timestamps of the event that
caused the launch and the timestamp of the last interaction with the
focused window. (Case 2 is handled by the application providing a
special timestamp of 0 for the launch time, which ensures that the
window that appears doesn't get focus)

If the newly launched window isn't focused, some things should be done
to alert the user that there is a window to work with:
  1) The _NET_WM_DEMANDS_ATTENTION hint should be set
  2) If the new window isn't modal for the focused window, it should
     appear below the focused window so that it doesn't obscure the
     focused window that the user is interacting with.
  3) If the new window is modal to the focused window, the currently
     focused window should lose focus but the modal window should
appear on top.

I don't know which was first metacity or mutter, but it seems that both projects use the same approach (https://bugs.launchpad.net/hundredpapercuts/+bug/495403/comments/9). I don't know why compiz insists on going a different route after more than 7 years of complains.