When I first read Dan Wood’s plan for Report-An-Apple-Bug Friday, I was amused but a little disgruntled by the idea. Turns out this once long-term Apple employee has a bit more loyalty than he thought he did. Or is it just empathy? The part that turned me off was the idea that everybody should cooperate in a “mass report” of the same issue. I suppose if it’s everybody’s pet peeve, that’s fine, but I almost got the feeling that the idea was to promote some kind of bug reporting solidarity regardless of personal investment in the issue.
Although a bug with lots of “marked as duplicate” tags on it may in fact get a bit more attention than it would otherwise, it was always my impression while inside that a more significant fast-trick to fixing was how the issue ranked on the Apple Support telephone logs. Think about it. It takes a mere 30 seconds to review a bug and mark it as a duplicate. The way most groups screen bugs, there is a dedicated group member who probably has all the common bug numbers bookmarked or memorized by now. When somebody calls in to discuss a problem, it costs toll-free telephone time, and probably at a minimum 5 minutes of a telephone operator’s time. While the operator probably makes less than the bug screener, they would have to make 10 times less for the cost of just the wasted salary to match the cost of marking a bug as a duplicate.
Perhaps if this movement really is meant to be a guerrilla campaign to control Apple’s bug fixing priorities from the outside, it should be dubbed “call 1-800-SOS-APPL Friday” instead.
Nonetheless, I like the reminder to get those pesky peeves out of my head and into the system. Don’t get me wrong, I’m an avid bug reporter as-is, but I do go through slumps where I just feel too lazy to navigate the sometimes obnoxious HTML-based bug reporter Apple provides.
Today I will participate for the first time in reporting a bug that directly affects the behavior of my application, FastScripts. I am also taking Mike Zornek’s suggestion of tagging this entry with the keyword “applebugfriday.” If that causes some new readers to come on board, then “hello, and welcome!”
The bug I’m reporting is a smaller part of a larger issue which has to do with the “rights of cursor ownership.” I already have an outstanding bug report from 2003 (#3260283) which addresses the bigger issue: Apple’s unfair practice of allowing the front-most application to change the cursor even if the user’s mouse is hovering over a floating UI that doesn’t belong to that application.
Until that bug is fixed we’re left with a scenario where a certain amount of courtesy is called for when it comes to manipulating the cursor. Most applications are well-behaved in this regard, but some are ridiculously rude. PowerPlant is especially villainous in this regard. All PowerPlant apps that I’ve encountered have a habit of constantly resetting the cursor back to a plain arrow. This means that if any UI floating over the app attempts to change the cursor, it is instantaneously switched back to an arrow by the offending app. A terrible UI results for all parties involved. The floating UI doesn’t get its point across. The user gets frustrated by the flickering cursor, and the application author gets embarrassed (I wish!) by its rude over-involvement with all things cursor.
For the most part Apple’s own applications are better behaved. One glaring exception is unfortunately the one Apple application that is always running: the Finder! And that is the target of my bug, today. Thankfully, the Finder doesn’t behave quite as badly as most PowerPlant applications (though it may have at one time when it was more heavily based on that framework). What the Finder does though, is listen for changes in the state of the modifier keys (shift, ctrl, etc.), and uses that opportunity to reset the cursor to whatever it feels is correct (always an arrow in my tests). This overrides any UI that might be presented in front of it, and any custom cursor which might help the user better understand the software that they are piloting. In FastScripts, I allow the user to perform certain shortcuts by selecting menu items with certain of these modifier keys held down. For instance, to easily change the keyboard shortcut of a script, the user can select it while holding down the command key. To aid the user’s understanding that a special action will occur, I change the cursor when the key is held down. The Finder, and other rude applications, are the bane of my application’s elegant user experience.
It’s not just FastScripts that is affected by this. A great example is shipped by Apple and used by (presumably) hundreds of thousands of people per day: the Dashboard. With the Finder as the frontmost application, activate the Dashboard. Now, move your mouse to any widget which has good reason to modify the cursor. For example, select the text entry field of the Translation widget. Notice the familiar “I-Beam” cursor appears, as we would expect. Now, simply press the shift key, or control key, or caps lock. Whatever. You’ve lost your I-Beam. Worse, to get it back you’ll have to coerce the widget into resetting it by activating another widget and then switching back. It has no way of knowing it needs to reset the I-Beam – it already set it once and it knows it doesn’t need to set it again! At least, in a predictable world it wouldn’t need to.
Ideally Apple would fix the root problem, and disallow the front application from willy-nilly changing the cursor when the mouse is positioned over a window that it doesn’t own. Failing that, Apple’s own products should showcase a more respectful attitude towards cursor rights. If another application is displaying meaningful UI above the Finder, then the Finder should stop hogging the cursor! Radar #4243655.