It seems to be, that the rule ought to be:

  • "if the operator's mouse/keyboard event which originally spawned the new window is still the last one generated, then it may grab focus"

In other words, if the user is WAITING on a window to pop up, then it takes focus. But otherwise (such as the user typing in another document) it does NOT take focus.

Of course, in this context, I refer to only key-down and mouse-down events, not passive events like mouse movement.

all 8 comments

sorted by: hot top controversial new old
[–] 11 points 6 months ago (6 children)

I prefer "focus follows mouse". The pointer is my indicator to the computer as to where my attention is. If a window is not under the pointer, it shouldn't have focus.

  • source
  • hideshow 6 child comments
  • [–] 4 points 6 months ago (4 children)

    Somebody downvoted this statement of a personal preference? wtf.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 4 points 6 months ago

    depending on type of window management it can appear above another window under your mouse cursor, in which case it stole the focus. imagine you're about to click a download button and instead a window with a delete prompt appears above the button and you confirm that instead. my point is: focus settings alone don't fix this.

  • source
  • parent
  • [–] 1 point 6 months ago

    It's not always clear what event created child windows.

    However, it is solved in many compositors / window managers. For example, per default Gnome will not focus a window from another app than the one you're using and show a notification instead.

  • source