Mail 2.0: ‘Quit Mail’ command not disabled when ‘Attach File’ dialog box is open

Posted by Pierre Igot in: Mail
August 10th, 2005 • 6:12 pm

This is another problem in Mail that just looks like sloppy programming on Apple’s part.

In Mail 2.0, compose a new message. Hit command-shift-A or select “Attach File…” in the “File” menu.

This opens a dialog box where you select the file(s) you want to attach to your message. While this dialog box is open, I’d expect the “Quit Mail” command in the “Mail” menu to be disabled, but it is not.

And if you accidentally hit command-Q while the dialog box is open (like I just did when I actually meant to hit command-A to select all files in a folder in order to attach them all to a message — which is how I found out about this), then things get very weird indeed.

First of all, the “Mail” menu heading becomes highlighted, as is normally the case when you hit a keyboard shortcut for a menu command. Only in this case it stays highlighted and nothing happens! The dialog box to attach files stays open, and you can proceed. So say you select a file and click on the “Choose File” button. What happens next?

Mail exits the dialog box and attaches the file to your e-mail message — but it still doesn’t quit, which is good, since your message is unsaved! So now you think that the accidental “Quit Mail” command has been ignored, right?

Think again! As soon as you do something that saves the message, like hitting command-S to save it as a draft or actually sending it, Mail promptly executes your command and… quits!


It looks like the standard behaviour for the “Quit” command in Mac OS X applications when a dialog box is open is not exactly clear. For example, in BBEdit, when the “Open File” dialog box is open, the “Quit BBEdit” command is disabled.

In TextEdit, on the other hand, the “Quit TextEdit” command is enabled, and if you select it while the “Open File” dialog box is open, TextEdit quits. If there is an unsaved document window in TextEdit at that stage, it does gracefully ask you whether you want to save it or not, with the standard pop-up dialog sheet. In other words, in TextEdit the “Open File” dialog box is not truly modal. You cannot bring another document window to the foreground while the dialog box is open, but the window of an unsaved document does come to the foreground if you hit the “Quit TextEdit” command while the “Open File” dialog box is open.

It’s rather strange. I think the BBEdit behaviour (disabled command) would be preferrable — but then BBEdit doesn’t use dialog sheets either for saving files, so in a way BBEdit behaves like a classic Mac OS application while TextEdit and Mail behave like truly modern Mac OS X applications, with their document-specific “Save As” dialog sheets and a “Quit” command that stays active even when a dialog box is open. (After all, you just might want to quit an application even while the “Open File” dialog box is open, right?)

The problem is that this means that the “Open File” dialog box in Mac OS X applications has a rather strange “semi-modal” status. It’s modal in that you cannot click elsewhere while it’s open, but it’s not modal in that you can still do some other things in the application while it’s open. It is like it “floats” somewhere in interface limbo, not attached to a specific document window (since it would have to be attached to a document window that doesn’t yet exist), but not attached to the application as a whole either (since you can still do other things in the application that have nothing to do with it).

It reminds me of the weird status in Mac OS X 10.4 of windows like the “Show All” window for the global Spotlight menu. It’s a window that doesn’t belong to a specific application — at least visually. (It does in fact belong to the “SystemUIServer” process, which you can see — and quit — in the Activity Viewer application if you show all processes. But “SystemUIServer” is not a separate application in the Mac OS X interface.)

Much in the same way that the Spotlight window doesn’t belong to any specific application, the “Open File” dialog box in a Mac OS X application — unlike the “Save As” dialog sheet — doesn’t belong to a specific document window. And that makes it a bit of a hybrid, ambiguous thing.

Maybe this particular problem could be solved by changing the whole behaviour for opening files… Instead of opening a semi-modal dialog box in interface limbo, why not automatically open a new document window with an “Open File” dialog sheet attached to it? It would be a bit like what happens when you try to create a new document in Pages. Pages opens a new document window, but immediately drops down a dialog sheet attached to that window that asks you to select a template for the new document. If you exit the dialog box without choosing a template, Pages closes the new document window altogether. If you choose a template, Pages dismisses the dialog sheet and gives you access to the new document window.

The whole concept of the “Open File” and “Save As” dialog boxes has always been a bit of a controversial issue from a user interface point of view. Some people feel that we should get rid of them altogether and force the user to go through the Finder.

With Mac OS X, Apple introduced the concept of the dialog sheet, which is attached to a specific window and works well for the “Save As” dialog. But they didn’t really come up with a solution for the “Open File” dialog box.

The solution I suggest would be a way to eliminate the ambiguity of the semi-modal “Open File” dialog box, since it would automatically always be attached to a specific document window.

Whatever Apple do, however, they should definitely get rid of this delayed application quitting behaviour in Mail!

Comments are closed.

Leave a Reply

Comments are closed.