New windows steal focus

Bug #455241 reported by Julien Olivier on 2009-10-19
106
This bug affects 21 people
Affects Status Importance Assigned to Milestone
Compiz
Medium
Unassigned
Unity
Confirmed
Medium
Unassigned
compiz (Ubuntu)
Medium
Unassigned
unity (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: compiz

In Karmic, new windows from any application are put in foreground even if I interact with another window before they appear.

In gconf, I have set "focus_prevention_level" to "2", and I also tried setting it to "4" but it doesn't change anything.

I tried opening gedit, then clicking on the launcher for firefox, then going back to gedit, and writing something. When the Firefox window appears, it's put in fullscreen even though I was typing in gedit. I also tried with other apps, and it's always the same behaviour.

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).

ProblemType: Bug
Architecture: i386
CompizPlugins: [core,move,resize,place,decoration,animation,ccp,dbus,mousepoll,gnomecompat,png,svg,imgjpeg,text,commands,neg,video,wall,snap,scale,scaleaddon,expo,staticswitcher,regex,resizeinfo,workarounds,ezoom,vpswitch,extrawm,fade,session]
Date: Mon Oct 19 09:48:45 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/compiz
InterpreterPath: /bin/dash
MachineType: FUJITSU SIEMENS LIFEBOOK S6120
Package: compiz-wrapper 1:0.8.4-0ubuntu1
PccardctlIdent:
 Socket 0:
   no product info available
 Socket 1:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
 Socket 1:
   no card
PciDisplay: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)
ProcCmdLine: root=UUID=f9db4586-2b56-4654-98eb-8d1c24a13343 resume=UUID=ed5930f7-3c96-4098-bf91-ca487d067c14 ro quiet splash locale=fr_FR
ProcEnviron:
 LANGUAGE=fr_FR.UTF-8
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.6.0-1ubuntu4
 libdrm2 2.4.14-1ubuntu1
 xserver-xorg-video-intel 2:2.9.0-1ubuntu2
 xserver-xorg-video-ati 1:6.12.99+git20090929.7968e1fb-0ubuntu1
SourcePackage: compiz
Uname: Linux 2.6.31-14-generic i686
XorgConf: Error: [Errno 2] Aucun fichier ou dossier de ce type: '/etc/X11/xorg.conf'
dmi.bios.date: 05/10/2004
dmi.bios.vendor: Phoenix/FUJITSU
dmi.bios.version: Version 1.26
dmi.board.name: FJNB16C
dmi.board.vendor: FUJITSU
dmi.chassis.type: 10
dmi.chassis.vendor: FUJITSU SIEMENS
dmi.chassis.version: S6120
dmi.modalias: dmi:bvnPhoenix/FUJITSU:bvrVersion1.26:bd05/10/2004:svnFUJITSUSIEMENS:pnLIFEBOOKS6120:pvr:rvnFUJITSU:rnFJNB16C:rvr:cvnFUJITSUSIEMENS:ct10:cvrS6120:
dmi.product.name: LIFEBOOK S6120
dmi.sys.vendor: FUJITSU SIEMENS
system: distro = Ubuntu, architecture = i686, kernel = 2.6.31-14-generic

Julien Olivier (julo) wrote :
Cory (cory-northwinddesign) wrote :

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

WeatherGod (ben-v-root) wrote :

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?

WeatherGod (ben-v-root) wrote :

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

affects: compiz (Ubuntu) → gnome-desktop (Ubuntu)
Changed in gnome-desktop (Ubuntu):
status: New → Incomplete
WeatherGod (ben-v-root) wrote :

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.

Julien Olivier (julo) wrote :

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.

Julien Olivier (julo) wrote :

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 ?

WeatherGod (ben-v-root) wrote :

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.

Julien Olivier (julo) wrote :

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 ?

Sebastien Bacher (seb128) wrote :

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

affects: gnome-desktop (Ubuntu) → compiz (Ubuntu)
Julien Olivier (julo) wrote :

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

Changed in compiz (Ubuntu):
status: Incomplete → Confirmed
thorstenmz (th-guenther) wrote :

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

kolen (incredible-angst) wrote :

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

Stephen M. Webb (bregma) on 2013-11-07
Changed in compiz:
status: New → Triaged
importance: Undecided → Medium
Changed in compiz (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Changed in compiz:
milestone: none → 0.9.11.0
Daniel Loureiro (loureirorg) wrote :

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.

Eleni Maria Stea (hikiko) wrote :

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).

Changed in compiz:
status: Triaged → Won't Fix
Changed in compiz (Ubuntu):
status: Triaged → Won't Fix
TomasHnyk (sup) wrote :

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

Eleni Maria Stea (hikiko) wrote :

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

Eleni Maria Stea (hikiko) wrote :

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

TomasHnyk (sup) wrote :

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).

Eleni Maria Stea (hikiko) wrote :

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

Changed in compiz:
status: Won't Fix → Confirmed
Changed in compiz (Ubuntu):
status: Won't Fix → Confirmed
Changed in unity:
status: New → Confirmed
importance: Undecided → Medium
TomasHnyk (sup) wrote :

(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)

Changed in unity (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Rodrigo (rodhos-hp) wrote :

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

tags: added: desktop-bugscrub-triaged
description: updated
Brad Erickson (eosrei) wrote :

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.

Jaime Pérez (jaime-91) wrote :

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

Brad Erickson (eosrei) wrote :

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.

Triqui (triqui) wrote :

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.

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

Other bug subscribers