Windows should not automatically be focused when opened if the focus is on another application

[Nathanael Schilling]

If this is not a bug, or not a unity bug, please delete this bug report.

There are times when I press alt +F2 to start an application and it takes a while to start. Meanwhile, I am typing something in the other application I have open, and when the app I started finally loads it "cuts me off" from typing as it focuses on the new application. A solution to this would be to start new windows, if they are not dialogue boxes that is, in the background automatically if another window is focused or if one is typing.

EDIT: smspillaz: sorry to hijack this bug. I get the impression here that the focus stealing prevention behavior is correct, however the real issue at hand is that windows that are denied focus
are stacked on top, and then you can't raise the actual focused window to the top until you focus the window that was denied focus. I'll fix that.

TESTCASE

Make something crash or something
Apport should come up underneath the window you are currently working with

[Bilal Akhtar (bilalakhtar)]

I don't think this would be a proper way to fix this problem. Imagine these user cases:
1) No windows are open, press Alt+F2 and open an application. If the application is, say, a web browser, and if it doesn't get focus, then the user would not be able to simply start typing to enter text in the address bar. He/she'd have to click the address bar once.
2) If its a small application which loads up quickly e.g. gedit, then it would be frustrating for the user to first start it from Alt+F2, and then click it again in the launcher, and then begin typing.

There can be many more such user cases which would be affected by such a change. Feel free to continue the discussion here on this bug. In the meantime I've marked it 'Opinion'.

[Nathanael Schilling (nathanaelschilling)]

I don't know what all the stati for bugs are, so I don't know what the correct status for this bug would be, though I'm not sure if "Opinion" is the right one, as as far as I can see it is a bug that is also fixable.

With regards to the two user cases above, it is clear that the mechanism for determining where to place a window needs to be somewhat "intelligent", as the current buzzword seems to be, i.e. it would need to take in several factors.

For example, say a user is typing into an application that is open, and does so whilst waiting for another application to open. In this case, I would say that it is obvious that the new window should not open in the foreground. This has been the setting where I have noticed this problem most, and which led me to report it. Basically, the function determing where to place the new window would need to know "what the user is paying attention to", and the only way, as far as I can see to determine this reliably would be if the user were clicking(in the case of a game) or typing much.

As for the first user case, it is clear that this function would also need to take into account whether any other windows are open in the current workspace and to place the window in the foreground if this is not the case.

With the solution outlined above, I think that this bug would be fixed for user cases such as the one where someone is typeing whilst waiting for an application above, without this solution affecting other user cases such as the ones given by Bilal Akhtar negatively.

[Bilal Akhtar (bilalakhtar)]

Needs design discussion; marking appropriately

[Omer Akram (om26er)]

There is an option in ccsm which you can change to your need, in ccsm, General Options>>'Focus & Raise behavior' there play with 'Focus prevention level' option if you want.

[Magnes (magnesus2)]

This is also a security bug. You could be writing a password when new windows focuses and you could by mistake write part of your password in the new window (and hit enter) - happened to me twice with firefox starting (so I googled my password by mistake).

[Marco Biscaro (marcobiscaro2112)]

I think the question here is the same of bug #717354.

[Nathanael Schilling (nathanaelschilling)]

@Mark : No, not quite. the bug you mention says that focus stays with the app that you open, whilst this bug addresses the problem of that not happening. A solution to both bugs, as Mark Shuttleworth pointed out in the previous bug report, is not changing compiz focus prevention levels but to have some sort of system which checks whether the previous window really needs the focus

[Nathanael Schilling (nathanaelschilling)]

This bug also strongly affects games. For example, sometimes my wifi will ask me for a password. If I am playing a game, this puts an ugly password dialog in front of the game, making it unplayable.

[mrpotato (estoyhartodeponernombres)]

I think the focus should be put in the aplication where the user lastly put his focus. For example:

I click on the launcher for Firefox, NetBeans and Gedit, in that order. All start launching and Gedit is the fastest one, so I start typing. With the current behaviour, Firefox window would get focus and I'd type in the address bar what I wanted to type in Gedit. Since the last launcher I pressed whas Gedit, the system should remain focus on it.

If, however, the last launcher I pressed were Firefox's one, Ubuntu should put his focus on it, since it is supposedly the application that I want the foucs on.

[Sam Spilsbury (smspillaz)]

This is a regression that happened when I changed the behaviour of the reparenting so that it would work with more applications. Unfortunately I haven't had the opportunity to look at it yet, but I'm making this a priority after the performance problems with the new decorator and the settings upgrade stuff that distro needs me to do for the next compiz release.

(Also, I'm sick at the moment, so this might take a little longer to get done than normal)

Cheers

[Franck (alci)]

I was on the way to report a bug and I found this report. So here is my view on it...

Current behaviour:
1) I have firefox opened maximized with focus
2) I go to the launcher, and click on nautilus (maximzed)
3) nautilus opens, on top of firefox, BUT, firefox still has focus, and global-menu if firefox menu. Buttons (close, miximze, minimize) are also related to firefox, not to the window currently displaying.
The is no visual hint is that Nautilus does not have focus, excpet that the menu is the wrong one (but both are quite similar)... So I want to access a remote place via the menu, and end-up seeing the list of firefox bookmarks instead...

So I don't know what the right behaviour would be regarding focus "stealing", but clearly if I launch an app with the launcher, I want it to have focus, especially if it is maximized !

[Nathanael Schilling (nathanaelschilling)]

But let's say you launch an app from the launcher that takes a while to
start, and you're in the middle of typing something. Wouldn't you rather
have that the app that you started starts in the background while you
are typing, but gives some visual indication of that?

[Franck (alci)]

@Nathanael: well, does not happen to me. If I interrupt my typing to open a new app, it's likely I'm switching tasks.
Moreover, I get a SSD drive, no app takes more than 1 second to open (or it will have a splash window like eclipse)... so we may have conflicting needs here.

[Nathanael Schilling (nathanaelschilling)]

True. with an ssd drive things are different. However, the approach I
suggested would work for you as well, as you interrupted typing to start
the app it doesn't have to be in the background. I'm sure there is a way
to tell whether the user is typing or not. Also, what about dialog boxes
for say wireless passwords and other such "popup" style applications....
do you think they should start in the foreground or background?

[Franck (alci)]

Hummmm... I guess if I launch an app, and before it opens I "give again" focus to another app (I mean, it could already have focus, but I click in the window again or give it some input), then I probably wouldn't want it to lose focus. Same for "poping" windows.

So... I would say that :
1) clicking in the launcher somehow gives the launcher focus
2) if the launcher has focus, it should give it back to the app it just opened
3) unless the user gave it to again another app inbetween.

That is, focus is controled by me, the user : this is a key point, or else the whole global-menu/hidden-menu is too weird, as it is directly related to the question : which app has the focus (or even which window, as some apps have multiple windows with different menus :-( ).

[Nathanael Schilling (nathanaelschilling)]

@Franck: I like that approach.

[Martin Pitt (pitti)]

Hello Nathanael, or anyone else affected,

Accepted compiz into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Sebastien Bacher (seb128)]

still getting the issue with update-manager there, if you run it on a workspace, select some update, click on "install" then switch to another workspace before the download dialog opens it will open on the other workspace with that issue still there

[Sebastien Bacher (seb128)]

while the bug is not fixed the new version doesn't seem to have issue and fixes other bugs, we should probably not block the SRU on the validation of that bugfix

[Sebastien Bacher (seb128)]

ok, Sam says the update-manager case though similar is another bug so ignore my comments I will file a new bug

[Ngassam Nkwenga (cyrildz)]

this behavior Still apply.

I'm on the proposed Repository

[André Ventura (afv)]

I confirm it isn't solved. (example: launching Banshee and switching back to Firefox, Banshee steals focus when ready).

[Nathanael Schilling (nathanaelschilling)]

I haven't actually tried whether the fix works or not, but thanks for
taking the time to look at the bug and (as it seems), fix it too :)

[Franck (alci)]

Well, I still don't know what the excpected behaviour is. Where is the spec ?

What I can see is :
- launch eclipse (take a while)
- open firefox and give it focus
- when eclipse finishes opening, it will show on top of Firefox and "steal" focus.

This behaviour is coherent, if eclipse opens on top of Firefox (and maximized) it must have focus (or else the global menu is incoherent with the app showing on top).
Another way could be to open eclispe underneath and let firefox have focus until the user switches to eclipse.

I don't see any clear design decision stated... but the current behaviour is fine to me.

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.6+bzr20110929-0ubuntu5

---------------
compiz (1:0.9.6+bzr20110929-0ubuntu5) oneiric-proposed; urgency=low

  * debian/patches/fix-864330.patch:
    - fix windows which can have towed moving (LP: #864330)
  * debian/patches/fix-864478.patch:
    - Window shading is broken (LP: #864478)

compiz (1:0.9.6+bzr20110929-0ubuntu4) oneiric-proposed; urgency=low

  * debian/control:
    - don't suggest nvidia-glx, it's part of the old initial packaging
      and probably a bad hint on non nvidia system (LP: #844218)
  * Cherry-pick upstream patches:
    - Windows should not automatically be focused when opened if the focus
      is on another application (LP: #748840)
    - Launcher - If a spread contains minimised windows, when the spread
      exits, the minimised windows momentarily appear on the desktop
      before disappearing (LP: #863328)
    - reproducible stacking bug in compiz (LP: #869316)
    - Click-dragging a window that's stacked above a fullscreen window will
      cause it to go underneath the fullscreen window (LP: #869919)
    - sometimes the keyboard input doesn't go to the apparently focussed
      dialog (LP: #869967)
    - Opening mumble can cause it to be stacked above the dash if you
      open the dash at the same time (LP: #865863)
    - Sometimes configure events are missed and windows move slow as a result
      (LP: #866752)
    - Workaround ubuntu desktop unity. Mouse at the left side doesn't reveal
      launcher (LP: #832150)
 -- Didier Roche <email address hidden> Wed, 12 Oct 2011 10:44:49 +0200