Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Focus stealing
3 points by makecheck on Feb 5, 2009 | hide | past | favorite | 6 comments
I've been a programmer for many, many years, and I see a problem all the time in modern systems that I don't understand: the stealing of keyboard focus.

My question for the other programmers among you, is: why is a theoretically simple concept like "focus", difficult for operating systems to manage properly?

In case you don't know what I'm referring to, here's an example. You're typing something in one window, and then some other window comes along that pops open and steals your focus away. So now, your typing continues in a new context, where each key now has new meaning. Worst case, you happen to hit Enter, at the exact time something like a message pops open, causing you to "accept" something that you didn't even read.

I have seen this with every OS, with many different applications, and with different window managers on Linux. It is pervasive, yet it is aggravating, which suggests to me that the problem must be "hard" or it would have been solved already. Right?




Never had this problem with RISC OS. For an added bonus, if you are using a menu and you select an item with the right mouse button, the menu remained open so you could then make further choices if you wanted to.

Fantastic operating system. Shame it's dying.


You would need a lot of real-world analysis to make this work right. Consider the case of 10 annoying dialog boxes that pop up in sequence, which the user presses enter to close. The no-focus-stealing OS thinks the user can't possibly respond to a new window in less than 180 ms, and redirects input to some irrelevant parent window. Yet in this case, the user is already in a beat pattern with the annoying dialog boxes, and is responding in < 50 ms.

There are probably a bunch of other special cases that are hard to imagine unless you're a full-time window-manager developer (I'm not.)


Great posting, this is one of my pet peeves of user interface design.

I really liked the old-style focus method of just having the mouse hover over the window that input goes to, instead of having to click it or having the window steal the focus of whoever is currently having the focus. I figure if I didn't do it explicitly then the os should certainly not allow some application to do it for me.

Notable exceptions: start of a new application, the current application.

Other than that just limit your 'stealing' to coming to the top of the windows stack but leave the focus where it is.


Have you seen this on the Mac?


Here's a Mac example. Sometimes I keep an iCal alarm alert dialog box open for long periods of time -- I know, not a great habit, but when I'm focused on programming, I just kind of push it off to the side. At a regular interval (every 10 minutes perhaps? just a guess), it steals the focus and moves to the top of the window stack. If the purpose is to re-remind me of an overdue alarm, shaking the dialog box or playing a sound would be better because I can mentally make note of it and keep working vs. having to re-click in my editor, for example, and retype whichever keystrokes disappeared into the iCal alarm abyss.


Sure. Say, when menus are open and being used, they will sometimes be forced to close by other tasks. I have had background processes such as Automator tasks steal focus for no apparent reason.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: