06.07.08

LSBackgroundOnly and AppleScript don’t play well together

Posted in Camino, Software at 5:05 pm by Smokey

It’s pretty rare that I write about a technical topic (or even a mostly-technical topic), since I’m not really what most people would consider a “developer.” When I have written about such things in the past, it has generally been surrounding our feed handler applications, and this time is no different.

Because the feed handlers function as faceless background applications (they simply receive an open location/GURL event, do a tiny bit of processing, then send Camino a open location/GURL with the URL of a web-based feed reader and a feed, and quit), users have the best experience when they don’t even really know the handlers exist. That is, users don’t see the feed handlers launching, and the apps don’t steal focus from what the users may be doing when the apps launch.

Often Mac developers use the LSUIElement key with a value of 1 in their application’s Info.plist to make their application “hidden”—it won’t appear in the Dock or the application switcher—but this doesn’t make an application a real background-only application; if the application has windows, those will still appear (for example, the Mac OS X crash reporter behaves like this), and applications like this can still steal focus. If you have an application that periodically launches and “does stuff,” like Camino’s feed handlers, there are lots of chances for unfortunate focus-stealing.

The solution to this is an alternate property list key, LSBackgroundOnly, for “faceless background applications.” Set this to key to 1 and all is well, right? In most cases, yes; all is well. However, if your application is an AppleScript, as Camino’s feed handlers are, you’ve just set yourself up for a world of random hurt. AppleScript has this old feature where applications configured not to show a “startup screen” (as faceless background applications would be) can still be forced to show the startup screen on launch (if your application does not have a custom startup screen because you never intended for it to show a startup screen, you get a startup screen like this gem ).

This override-the-decision-not-to-show-a-startup-screen is triggered by whether or not the Ctrl key is pressed when the application launches. In an LSBackgroundOnly application, any UI displayed by the application is stuck in this limbo z-layer, where it is sort-of visible if you move other applications out of the way, but never focusable (on 10.3.9, the startup screen isn’t even visible at all!). As a result, if your LSBackgroundOnly AppleScript application launches when the user is pressing the Ctrl key (in any application: Camino, Finder, Terminal, etc.), the startup screen appears and can’t be dismissed, preventing your application from running or quitting. Yikes! The only way to terminate a stuck LSBackgroundOnly AppleScript application is to use a terminal command or Activity Monitor; neither is very user-friendly, and both assume that your users can figure out what’s happened in the first place.

As a result of this old AppleScript (pointless—why would you ever want to show a startup screen in an application you’d explicitly saved to not have one?) behavior, the user-friendly, impossible-to-notice faceless background-only application becomes a very visible, very unfriendly application staring your users in the face, taunting them because it can’t easily be closed—and, to top it all off, your application isn’t really running, so it can’t even perform whatever function it’s been designed to perform. Unless you can be perfectly sure that your users will never be pressing the Ctrl key when your application might launch, you will find that AppleScript is unsuitable for creating faceless background applications.

Ultimately, someone else will probably rewrite Camino’s feed handlers as tiny Cocoa apps, but for any Apple types out there, I did log this behavior as rdar://5962612 and suggest that LSBackgroundOnly AppleScript applications ignore the Ctrl-to-force-startup-screen behavior (though based on other, less painful, problems this causes, I don’t think many would cry if the Ctrl behavior were sent the way of Mac OS 9).

Permalink