Focus stealing [LWN.net]

Focus stealing

Posted Aug 18, 2005 21:27 UTC (Thu) by zblaxell (subscriber, #26385)
In reply to: Focus stealing by newren
Parent article: GNOME and the way forward

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

(Log in to post comments)

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.