Open Radar

 
25-Mar-2009 06:08 PM Michael Lowry:
Summary: 
With Mac OS 9, when you brought an application to the foreground, it remained in the foreground until you took action. With Mac OS X, it has become possible for an application that is in the background to force itself to the foreground.

Steps to Reproduce:
There are a number of situations even in the Mac OS X Finder where one part of the application will steal focus and interrupt the work of the user. But the most egregious offenders are third-party applications.

Expected Results:
When an app is put in the background, it remains there, providing notifications via the Dock icon or Growl when the user must be notified of something. When an application is already in the foreground and wishes to notify the user of something, it should do so without interrupting the user's current task.

Actual Results:
Apps can leap to the foreground whenever they please. Apps throw windows and dialogs in front of the user's work, interrupting text input. This can even lead to the situation where the user continues typing without realizing that his keystrokes are being interpreted by the window or dialog box that has since leapt to the foreground. This is not only annoying; it's dangerous.

Regression:
N.A. 

Notes:
I realize this is a vague bug, but I still think the topic merits consideration. I would like Apple to seriously consider technical improvements to the OS and to Apple's apps, as well as providing better guidance to software developers on how software should work. I would like to see something along the lines of a general recommendation that focus stealing not be used but in the most limited of cases.

26-Mar-2009 11:16 AM Michael Lowry:
Here’s one example of focus stealing: If Time Machine encounters an error when making a backup, it pops up a dialog box to inform the user. This dialog box leaps to the foreground even if the Finder is not the frontmost application. The dialog box blocks input until it is dismissed, interrupting work the user may be doing in another application.

30-Mar-2009 03:58 PM Michael Lowry:
Here is another example of a built-in app stealing focus: I established a VNC connection using Cmd-K in the Finder. The server is on a slow network, so it always takes a few moments to establish the connection. Therefore I switched back to my text editor to continue working on a web page I’m editing. In the middle of typing a line of HTML, the Screen Sharing app jumped to the foreground, and the second have of the line I was typing went to the remote computer instead of to the local text editor.

03-Apr-2009 11:15 AM Michael Lowry:
Here is yet another example. In this example, the problem is related to the inconsistency between two paradigms of window management.

Paradigm 1. One layer per application.
In Mac OS 9, each application belonged to its own layer. Bringing one window to the foreground would bring the whole application to the foreground, including all of its windows.

Paradigm 2. One layer per window.
In Mac OS X, windows of a single application no longer belong to the same layer. it is now possible to possible to bring to the foreground a single window of a an application that was previously in the background. Bringing this single window to the foreground does not bring to the foreground other windows belonging to that application.

Now here’s where focus-stealing enters the picture. Under paradigm 2, it is possible to arrange a stack of windows belonging to alternate applications, as shown in the attached file “5 windows.png”. At this point, the text document “Untitled 3” is in the foreground. The next window below it is a Finder window. When one closes the frontmost text document window, the next-highest window belonging to the same application (the text document “Untitled 2”) jumps to the foreground, leaping in front of the Finder window and overriding the arrangement of windows made by the user. See the attached file “4 windows.png”.

When the UI objects move or change in the absence of direct manipulation from the user, the illusion that the user is working with real THINGS is shattered. In the real word, things do not behave like that.

The user interface designer is faced with a dilemma: either allow this sort of behavior, where a background window steals focus but the foreground application remains the active one; or maintain the arrangement (back-to-front) of windows and allow a different application to become the active one. This dilemma is a direct result of these two implied assumptions in the current design of the user interface:
1. At least one window must be in the foreground at all times; and
2. The application to which the foreground window belongs must be the active application.

OpenDoc can been seen as, among other things, an attempt to make this sort of problem irrelevant. In a document-centric user interface, a document is in the foreground, and one doesn’t speak of applications being in the foreground or background. This was a noble effort, but largely failed.

I believe it would be worth seriously investigating ways to reconcile the two window management paradigms, to prevent the sort of user interface inconsistency described above.


'Window management paradigms.zip' was successfully uploaded