Focus stealing [LWN.net]

Focus stealing

Posted Aug 18, 2005 16:36 UTC (Thu) by tjc (subscriber, #137) [Link]

> But most users launch an application and then want to use it; defaulting to not focusing new windows just doesn't make sense.

You missed a step.

1. Launch application.
2. Drink coffee or pop for 10 seconds while you wait for all the shared libraries to load.
3. Use application.

Skipping step 2 results in a lot of frustration, which leads to criticism. Maybe this problem is more acute than it used to be, now that software takes so long to load. If no-one has the will to address the 10-second load time, then maybe the UI needs to be altered to accomodate it.

Focus stealing

Posted Aug 18, 2005 16:49 UTC (Thu) by newren (subscriber, #5160) [Link]

Hehe ;-)

Honestly, though, the 10 second load time is being addressed; that's what focus-stealing-prevention is for. Perhaps you were trying to use this as a reason to request never-focus-new-windows but like others here, you're not really addressing the issue and just listing cases that it looks like we've already covered.

Now, if you said, "Yes, launched windows shouldn't steal focus if the user works with another app between the time the window is launched and when it is shown--but that doesn't work without apps being launched with startup-notification which may not be feasible for us terminal users and we'd really like a preference, even if a kludge, to just not focus new windows" or if you said "Yes, most users launch an app then use it but us terminal users like to launch multiple apps without using them until a delayed time later so could we have a way to make the WM behave smart given our different usage scenario?" (see also bug 151818 comment 22, second half of point 8 for where I addressed this exact case) then I'd have an easier time understanding. In particular, though, I'd like to know more about the "behave smart" in the latter case--what do should be done relative to focus? placement? stacking? interaction with keynav? etc., etc.

Focus stealing

Posted Aug 18, 2005 18:02 UTC (Thu) by tjc (subscriber, #137) [Link]

> Perhaps you were trying to use this as a reason to request never-focus-new-windows but like others here, you're not really addressing the issue and just listing cases that it looks like we've already covered.

No, I'm not. I've learned from experience that requesting anything from the Gnome development team is pretty much a waste of time.

> Now, if you said, "Yes, launched windows shouldn't steal focus if the user works with another app between the time the window is launched and when it is shown--but that doesn't work without apps being launched with startup-notification which may not be feasible for us terminal users and we'd really like a preference, even if a kludge, to just not focus new windows"

Depending on well-written apps to deal with the problem just about eliminates any chance that the problem will be completely fixed, ever.

> or if you said "Yes, most users launch an app then use it but us terminal users like to launch multiple apps without using them until a delayed time later so could we have a way to make the WM behave smart given our different usage scenario?"

Forget about launching from a terminal, launching from Gnome panel is a problem. It still takes 10 seconds to load some apps, and I don't want to sit around doing nothing for 10 seconds while I wait, and I sure don't want to be interrupted by a new window stealing the focus.

I know this problem is difficult to fix, but that doesn't mean that it isn't a problem. The fact that Windows XP handles this better than X should be some motivation to bite the bullet and fix the problems with X before writing a lot more software for a broken architecture. If it's a lot of work and disruption now, it will just be a bigger mess 5 years from now. The time to fix this is before Gnome gains widespread enterprise deployment, not after.

The alternative is to hire a bunch of marketing people to try and tell us that it's not really broken, all our friends like Gnome, it must be you, etc.

Focus stealing

Posted Aug 18, 2005 18:24 UTC (Thu) by newren (subscriber, #5160) [Link]

I've learned from experience that requesting anything from the Gnome development team is pretty much a waste of time.

I'm sorry you feel that way. I hope I'm not part of the problem (though I probably am--I can't even get a small amount of the stuff done that I'd like to do myself), but for what it's worth I personally am trying to both (a) get things to work right for the default case (the normal "Gnomeish" response) and (b) cover extra important edge cases and smaller usage scenarios where merited with additional options (that's the whole reason for my lengthy posts here--I'm not sure I fully understand strict pointer focus and the requests for it but I would like to).

Focus stealing

Posted Aug 18, 2005 19:16 UTC (Thu) by tjc (subscriber, #137) [Link]

> I hope I'm not part of the problem

No, your not. My dissatisfaction dates back to the transition from Gnome 1.x to 2.x.

Focus stealing

Posted Aug 18, 2005 20:27 UTC (Thu) by pimlott (guest, #1535) [Link]

> I hope I'm not part of the problem

Please take this message in good faith.

Consider your long reply to Jon ("Maybe because ..."). The tone of that message, as I read it, is, "let me tell you all the reasons that what you want is wrong (and PS you don't really understand what you're asking for)". Why not instead start from the premise that Jon is an intelligent, experienced, and thoughtful user, and therefore that what he wants is reasonable and valuable? Think, "satisfying Jon's request might make GNOME a better desktop", or even "making Jon a happy user could earn some serious karma".

I'm not suggesting you would ever intentionally belittle Jon. But I think many GNOME (and Mozilla) developers tend to read user complaints with a mindset of "correct him" rather than "learn from him".

Focus stealing

Posted Aug 18, 2005 21:13 UTC (Thu) by newren (subscriber, #5160) [Link]

Oh, crap. I didn't even realize I was coming across that way. Sorry about that, Jon. /me goes and bashes his head into the wall as penance

For what it's worth, I really did mean to come across as "the request as you've written probably isn't what you mean--could you clarify?" with a really verbose explanation of why I think he might mean something different. (I think he was getting at the fact that he didn't like the default of focusing new windows in the cases where there is no user interaction between launch and appearance of the window or when we don't know enough about when various user interactions occurred, but what he suggested encompassed way more--and I don't know if the extra stuff was intended or not. After working on a WM long enough you find that people request all kinds of variations of things and I really don't know what's being requested without getting more detail)

Other comments in this thread are similar; I think most all of them are getting at that specific default, but actually use examples that are tangentially related and/or include lots of other stuff that may or may not be intended. I really am trying to understand what the real issue is.

Again, sorry for coming across that way.

Focus stealing

Posted Aug 18, 2005 21:32 UTC (Thu) by corbet (editor, #1) [Link]

No offense taken.

FWIW, what I want is this: the window under the pointer has the focus, always. If focus remains when the pointer goes onto the background, that's OK. If some rude application grabs it, there's little to be done - but that should not happen for much of anything beyond things like pulldown menus. If a window pops up under the pointer, let it have the focus (in this case, there is a lot to be said for predictability of window placement, which metacity pretty much has).

In another posting you said, I believe, that the above was not possible with X. But it used to work that way. It's only with GNOME 2 that I started running into weird focus stuff.

Honestly, to me, the "focus stealing prevention" stuff which tries to figure out if you are actively engaged with another application or not looks like an ugly hack. Something like that will always be problematic to get right. It's a highly modal, timing-dependent interface which seems guaranteed to surprise people. My own experience says that, when you start looking at that sort of approach, you've missed a turn somewhere. In focus-follows-pointer mode, at least, why not just leave the focus under the pointer? It must be possible; the bare X server works that way by default...

Focus stealing

Posted Aug 18, 2005 23:18 UTC (Thu) by newren (subscriber, #5160) [Link]

FWIW, what I want is this: the window under the pointer has the focus, always. If focus remains when the pointer goes onto the background, that's OK. If some rude application grabs it, there's little to be done - but that should not happen for much of anything beyond things like pulldown menus.

Okay, you reiterated that you want the window under the pointer to always have focus. But then you went and stated two exceptions. So you don't really mean for the rule to apply rigidly--but in what other cases should it not apply, if any? Here's some questions: If the user clicks on an item in the window list on the taskbar, should it be a no-op (sounds like that makes the window list applet useless--should the WM to disallow the existence of window list and window selector applets for your preferred focus mode? or is it okay to break the window-under-the-mouse-has-focus constraints here too?) What if the user tries to use alt-tab or alt-esc to switch which application has focus (no-op and break keyboard navigation? suspend mouse navigation rules temporarily since the user isn't using the mouse to navigate? warp the pointer?) What if the mouse pointer is over the background, the focus is on app A, and the user wants to use the keyboard to move app A from its current workspace and place it two workspaces to the right -- but app B has a window right where the mouse is in the intermediate workspace? In this case, if you focus app B after the first workspace switch (because it is under the mouse after all), then the user will be surprised if they rapidly hit the keybinding twice--they will have expected app A to move two workspaces but instead it only moved one while app B also moved one (yes, this was a real bug report--I'm not making it up). Is it okay to ignore the window-under-the-mouse-has-focus case here too? What about windows that don't take input focus?

I think that what you want is sloppy focus with its invariant (focus should be on the window under the mouse if there is one, otherwise focus should be on the most recently used window) held to be more important than focusing new windows with everything else kept the same, i.e. a don't-focus-new-windows-option. We explicitly decided to break the invariant in the new window case merely because the majority of users are surprised if new windows don't get focus (see our how to get focus right document and search for "strict"), but I believe we could add an option for not breaking the invariant in this case. I'm guessing that's what you want...am I right?

In another posting you said, I believe, that the above was not possible with X. But it used to work that way.

Look a little closer. Try this: bring up the menu in one of your apps, but don't click any of the items. Move your mouse to a different window altogether. Note that the application with the menu open still has focus and the menu is still up, and the window you moved the mouse into doesn't have focus. The application with the open menu has a mouse grab so that the WM doesn't know about the mouse entering the new window and is powerless to enforce the constraint you requested. (Note: there are some apps for which this little exercise won't work as they don't actually do a mouse grab, but most all apps do)

Also, try this: Open up a nautilus window. Pick an item and start dragging it elsewhere, including over other windows as though you were going to drop it on one of them. Notice that none of the windows get focused or raised when you move over them. We would really like to focus and/or raise those other windows when the user drags items over them to help them drop it in the right location (especially since it may be obscured), but we can't because the app where the DnD started has a mouse grab (although maybe if gtk+ sent the client messages for XDND with a nonzero event mask then maybe we could workaround this? I need to get an answer from Owen on that...)

I don't believe that either of those cases worked any differently in past with an X window manager (though there are efforts at fixing the latter via alternative methods and I believe I heard that KWin might have that up and running for QT apps at least...). Yes, we could get closer to having window-under-mouse-has-focus, but we can't make it 100%--and there are many ways in which it's not 100% where even most users of focus follows mouse probably don't want things changed. (And yes, I'll grant that the new window thing apparently is an example of where there's a large number of focus follows mouse users who do want a change to bring it closer to 100%, and that specific case is listed in the how-to-get-focus-right document I referenced above, but I'm not at all convinced that changes are wanted/needed for the other cases--at least, not yet).

Focus stealing

Posted Aug 22, 2005 5:03 UTC (Mon) by EricBackus (guest, #2816) [Link]

newren wrote:
> Okay, you reiterated that you want the window under the pointer to
> always have focus. But then you went and stated two exceptions.

Actually, I see only one exception in Jon's response--an application
grabbing the mouse. And I think both he and you acknowledged that there's
nothing for the window manager to do in this case anyway.

I'm not a Gnome user, so maybe my opinions on this are not very important.
For what it's worth, I use KDE set to "Focus Follows Mouse", which DOES
give the focus to new windows. But there is an alternative setting "Focus
Under Mouse" which sounds like it does exactly what Jon is asking for.

In response to your questions, I can provide my own answers:

* The window list on the taskbar, like many things on the taskbar, is a
special case. I'd expect having the mouse over the taskbar to be much
like having the mouse over the background, so I don't see anything
contradictory about making a click on the window list switch window focus
just as though you briefly moved the mouse over the new application.

* Alt-tab or alt-esc could perhaps warp the pointer. If you don't warp
the pointer, perhaps you could merely top the selected application, but
leave focus wherever the mouse is. I don't use these so I don't really
have an opinion.

* I also don't use the keyboard to move applications between workspaces.
But if I did, and doing this puts the mouse over a different application,
it sure seems like it *should* give that application the focus.

But the above answers aside, I suspect that what Jon wants is simply to
have new applications NOT automatically get focus, while leaving
essentially everything else about window focus alone.

Focus stealing

Posted Aug 30, 2005 6:04 UTC (Tue) by newren (subscriber, #5160) [Link]

Sorry for the slow response...

> Actually, I see only one exception in Jon's response--an application
> grabbing the mouse.

The other was "If focus remains when the pointer goes onto the background, that's OK." There is always a window under the mouse, even if it's the background window (the thingy drawn by nautilus with the icons on it) or the root window when nothing like nautilus is running (the root window will be a concept most users are unaware of as it's kind of an x implementational detail though it is exposed to some extent in some environments so some users do know about it). Allowing a window to retain focus despite the mouse being over a different window, such as the nautilus background window or root window, is an exception to the "window under the pointer has the focus, always" rule. Some users may not realize that it's an exception, but that's kind of my point--there are likely other exceptions that the user doesn't know about or doesn't realize that they are exceptions. I want to know what the exceptions are and what aren't.

> But there is an alternative setting "Focus
> Under Mouse" which sounds like it does exactly what Jon is asking for.

It may be exactly what he's asking for, but that's what I'm trying to find out. Note that "Focus Under Mouse" in KWin destroys keynav (as claimed by KWin itself). That seems strange to me. It may actually be what users want, but I wanted to find out if perhaps something that doesn't focus new windows without destroying keynav might be more desirable. There's a number of other behaviors I need to get nailed down as well...

> * I also don't use the keyboard to move applications between workspaces.
> But if I did, and doing this puts the mouse over a different application,
> it sure seems like it *should* give that application the focus.

Yeah, that's the initial response of everyone that hasn't tried this (and it was the way I initially coded it too; I definitely was in the "everyone" group at one point). It seems to make sense. After all, if a user switches workspaces without moving a window with them we definitely want to focus the new window under the mouse. It isn't obvious without looking closer why things would be different when bringing a window with you while switching workspaces. So, let's look a little closer...

Let's say you were trying to move the original application, A, two workspaces to the right using keybindings. If the mouse is over the desktop instead of A, but A is still active (meaning that this can only happen with "sloppy" focus) then there's a special case: If another application, B, happens to be at the same coordinates where the mouse is in the intermediate workspace, and we focus B after the first workspace change like you suggest, that will make it impossible for the user to get application A where they want it without moving the mouse. But the thing is, users aren't aware of this. Instead, they just do this expecting things to work and then get really surprised when A moves only one workspace and B ("some random app") also moves one workspace...and it does take them a while to figure out what is really going on. Further, even if the user only moves one workspace over, they are moving A with them which means they almost certainly have an intent to continue interacting with that window (just as if the user alt-tabbed to it).

So focusing B really doesn't make sense (at least not for any use cases I've ever seen--maybe there are users out there, perhaps ones that don't mind keybindings being broken altogether, that would like this?). Anyway, ever since we switched from focusing the window B in this specific case, all the complaints about this issue stopped (which is surprising--virtually any change you make in a window manager, including "obvious" bugfixes, almost always results in bug reports with people requesting an option for the old behavior).

> But the above answers aside, I suspect that what Jon wants is simply to
> have new applications NOT automatically get focus, while leaving
> essentially everything else about window focus alone.

Good, I'm glad to hear that someone else is coming to the same conclusion. :-)

Focus stealing

Posted Aug 19, 2005 4:39 UTC (Fri) by pimlott (guest, #1535) [Link]

>/me goes and bashes his head into the wall as penance

Now, no need to hurt the wall. :-)
Thanks for thinking about what I said, whether it was right or not.
FWIW, I use FVWM, and my alt-tab handler focuses, raises, and warps the pointer to the selected window. Although several other aspects of the alt-tab behavior are sub-optimal, warping the pointer seems to work out fine.

Focus stealing

Posted Aug 18, 2005 21:27 UTC (Thu) by zblaxell (subscriber, #26385) [Link]

While you raise some valid points, I think some of the problems you mentioned have already been solved by non-GNOME projects.

a) Applications can grab the mouse so that the WM isn't notified of mouse entry/exit from windows. Open up a menu in some app, move the mouse to another app--note that the window with the menu open still has the focus. Fixing would require re-writing all applications.

I routinely hit Ctrl-Alt-Divide on the keypad to break these, e.g. when I've popped up 2 levels of menu, then realized I have to go visit some other application to get information required to make a decision. It's usually worth the finger gymnastics on the keyboard to avoid having to describe the curvy path to the Nth level deep menu with a touchpad twice.

The applications don't seem to mind, and I didn't have to rewrite them, I just dishonor their input grab requests from the X server. In fact, I often wonder why it ever seemed necessary to grab the mouse or keyboard focus for these operations in the first place, since the menus work just fine without it, and modifying any particular application or toolkit to work that way is trivial. There are really good reasons to not grab the mouse and keyboard--especially if the application is prone to locking up while it has a menu posted.

b) Imagine this: User starts an application, while waiting they go to interact with some other app and clicks around on it, the launched application window happens to appear and covers the window(s) the user was working with (or do you expect new windows to be placed at the very bottom of the stack of windows?), and then the user clicks before they realize that a new window has appeared and thus initiates some action they didn't want.

Ratpoison has permission bits on raise and display requests that users can grant or revoke at will, with different policies for transients and non-transients. Control over these bits is considered a normal window management operation: users can have key bindings to switch windows, resize windows, and set "rudeness" bits as they like--it's not buried under four levels of user menus and dialogs, it's something that might change as the user switches from one application to another, depending on the user's current task. The feature is also exactly where it belongs--in the window manager, not the application. The effect is nice--no matter how obnoxious your mail client or web browser is, it can't interrupt your work by popping up a window on top of what you're doing, until you explicitly permit it.

In the GNOME or KDE context, there could be a little button in the taskbar, like the keyboard language indicator, which a user can click on when they don't want to be bothered by new windows for a while. It might even be reasonable to provide a mode where new windows appear on the bottom of the stack instead of the top, although if it was technically feasible, I'd try to get the new window to be immediately below the window with the mouse cursor, and first in the Alt-Tab list. Forcing all new windows to be minimized would work too, although I wouldn't be surprised if there was at least one application that would just try to un-minimize itself.

c) Your suggestion breaks the taskbar ("window list applet"), the window selector applet, alt-tab, and all applications that try to transfer focus from one of their windows to another. Effectively, it's impossible to do keyboard navigation.

twm never seemed to have a problem with this. twm did have rules about warping the mouse cursor--if you used keynav to select windows in twm, the mouse cursor moves at the same time. That was annoying, but from a user's point of view, it didn't break the "focus strictly under the mouse" rule, and I'll take annoyingly consistent over consistently annoying any day.

Another quirk is that pointing at the "icon list" in twm (the closest thing to a taskbar) put the keyboard focus on the corresponding application window. I could hit Ctrl-Q repeatedly while panning over the task list with the mouse to get rid of a lot of windows of some application or other. Unlike the usual "Close all" popup menu, I could send any keyboard command to the applications.

Digression: I wish more window managers would implement alt-Tab the way sawfish used to: as you alt-tab through the windows, it pops up each window to the top--and if you keep going, it pops the window back to its original place in the stacking order. This is really handy if there are 20 or so windows on the desktop and I want to pick out three of them in no particular order. I tend to leave a lot of windows lying around with just what I want to see exposed on each, so it's a fairly large investment of my time to fix things if the stacking order gets changed in indiscriminate ways. Sawfish is a little broken now--it moves application focus but no longer moves the mouse cursor, which can result in the mouse cursor on one window but the focus on another.

(d) there's not always a window under the mouse

There is always a window under the mouse. As far as I know the mouse can't be anywhere except above the root window, and one can't delete the root window.

(e) some windows shouldn't get focus ever even if the mouse is over them

Which are those? I've seen some applications (mostly Xaw) that can't get focus with some window managers even when they want it and can get it under twm...I had assumed that was a window manager bug.

f) I understand that among those that use terminals heavily, there are many that like to launch applications in the background and continue working. But most users launch an application and then want to use it; defaulting to not focusing new windows just doesn't make sense.

It's not unusual for me to launch applications two or three at a time, especially if I need to have two or three of them working together on a project. I also have applications that have extremely long startup times (e.g. Galeon after a crash may take up to 10 minutes to become fully usable).

I sometimes do corbet's xv and ^C trick. Sometimes it doesn't work, e.g. when the xv window fills the whole screen and focus goes where the mouse is--on xv. There's an xterm trick which is to put the xterm in "secure keyboard" mode, which is essentially just a permanent input grab. Unlike the way that input grab usually used by menus, an input grab on xterm is actually useful, and AFAICT it's a feature missing from gnome-terminal and konsole.

Ideally the window manager could do this consistently across all applications--e.g. the window menu might have options that mean "lock keyboard input focus on this window until further notice" with options "even if I manipulate other windows or new windows appear" and "even if the window closes, no other application gets focus until I explicitly allow automatic focus selection again."

Focus stealing

Posted Aug 18, 2005 22:24 UTC (Thu) by newren (subscriber, #5160) [Link]

Lots of interesting info in your post. Thanks! Some comments:

The applications don't seem to mind, and I didn't have to rewrite them, I just dishonor their input grab requests from the X server. In fact, I often wonder why it ever seemed necessary to grab the mouse or keyboard focus for these operations in the first place, since the menus work just fine without it, and modifying any particular application or toolkit to work that way is trivial. There are really good reasons to not grab the mouse and keyboard--especially if the application is prone to locking up while it has a menu posted.

Really? I had assumed (never actually checked) that it'd be a lot of hard work to modify toolkits to work without mouse and keyboard grabs. From the few things I had read on the matter, though, it doesn't look like toolkit authors are willing to make such a change--perhaps it causes lots of race conditions or other problems? (Man, I'm exposing my ignorance here...)

although if it was technically feasible, I'd try to get the new window to be immediately below the window with the mouse cursor, and first in the Alt-Tab list. Forcing all new windows to be minimized would work too, although I wouldn't be surprised if there was at least one application that would just try to un-minimize itself.

It's not very hard at all to place windows below the focused one and first in the alt-tab list. Also, the WM gets MapRequest events whenever an application tries to map a window (unless it's an override redirect window) and can just deny or delay the request so it could keep apps from un-minimizing themselves for the most part.

as you alt-tab through the windows, it pops up each window to the top--and if you keep going, it pops the window back to its original place in the stacking order.

Try using Alt-Esc in metacity. Other WMs may have something like that too with an alternate keybinding.

There is always a window under the mouse. As far as I know the mouse can't be anywhere except above the root window, and one can't delete the root window.

Yes, I unfortunately used "window" as the user thinks of them instead of as the real X objects. Note that mose focus-follows-mouse users prefer a sloppy style meaning that windows are focused when the mouse enters them but they are not defocused on exit--and users don't consider the root window and other special windows (e.g. the taskbar) to count when the mouse enters them. Saying always keep the focus under the mouse is nice and all but this is just an example of how most people don't really mean that.

Which are those? I've seen some applications (mostly Xaw) that can't get focus with some window managers even when they want it and can get it under twm...I had assumed that was a window manager bug.

See section 4.1.7 of the ICCCM (e.g. at http://tronche.com/gui/x/icccm/sec-4.html). Basically, it's a violation of the ICCCM for the window manager to try to set focus to a window with the input field set to false.

Focus stealing

Posted Aug 18, 2005 23:29 UTC (Thu) by zblaxell (subscriber, #26385) [Link]

From the few things I had read on the matter, though, it doesn't look like toolkit authors are willing to make such a change--perhaps it causes lots of race conditions or other problems? (Man, I'm exposing my ignorance here...)

There are one or two differences, especially in the select-no-entry case. With a grab you can have the user click on some non-menu surface, and keyboard accelerators can be used no matter where the mouse is. I'd imagine some users believe that they'd have to click off-menu to abort a menu selection (I once believed that, and it might be true for some applications with a do-it-yourself toolkit) as opposed to pressing Escape, or clicking on-menu and dragging off. Also, arrowing your way through the menu instead of using the mouse works only if the application that posted the menu already has keyboard focus for other reasons. Some menus in some toolkits will close if focus goes to another application while the menu is active. However, despite all the small changes, no menu that I've ever seen becomes unusable--all possible options, including "none of the above" can be selected with both keyboard and mouse.

I wouldn't be surprised if there weren't a lot of applications out there that are built assuming the GUI toolkit is incapable of receiving input from other widgets while a menu is active. That would probably break a few programs, but none of the ones I've tried.