Bug Report Friday
September 2nd, 2005When 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.
September 2nd, 2005 at 6:13 pm
Interesting bug. However, your example w/regards to Dashboard and the Finder doesn’t “work” for me. After selecting the translation widget’s text entry field, it changes to an I-beam as you noted. But when I select shift or control or command, the I-beam doesn’t change. The only one that causes it to change is option (which changes it to a crosshair), but this is correct, since in Tiger, you use the option key to select columns of text.
Maybe you can point to a better example?
— Simone
September 2nd, 2005 at 6:30 pm
Interesting! I’m curious if you’re running 10.4.2 (Finder version 10.4.1)? I wonder if there’s something about the way I’ve got Finder configured that causes the behavior. I assumed it would be universal.
Thanks for the feedback, it’s helpful to know that there might be some cases where the bug doesn’t occur.
I couldn’t find any other obvious examples of built-in software from Apple that demonstrates the bug. If you can think of another floating window that has a changing cursor, I’d love to try it.
September 2nd, 2005 at 7:19 pm
I am indeed running 10.4.2, with Finder 10.4.1. I didn’t see any mention of whether you are running that version or not, though.
Perhaps the problem is caused by some sort of extra contextual menu plugin or input manager. (Look in ~/Library/Contextual Menu Items/ or /Library/Contextual Menu Items/ and ~/Library/InputManagers/ or /Library/InputManagers/ respectively.) Maybe you could take these out and see if the problem still occurs? You could also try a safe boot (hold shift during startup) to see if the problem is still there — this effectively disables all third-party extras, I think, so you could do this in lieu of the first test. (Apologies if you’ve already tried these; just covering the bases. :) )
The only thing that I could think of, off the top of my head, that qualifies as built-in software from Apple that has a floating window and a changing cursor is the password assistant. Open up System Preferences, go to Accounts, start creating a new account, and then click the little key icon next to the password field. The text field for the password in the floating window that pops up also changes the cursor to an I-beam. And again I have the same effect as the Dashboard example you suggested — only the option key changes the cursor, and it does so correctly. (Make sure that the floating window is frontmost; this can be hard to tell sometimes.)
Heh heh. RAB Friday is fun!
— Simone
September 2nd, 2005 at 8:48 pm
I didn’t in fact check the obvious, until your comment prompted me to :) But I’ve just confirmed that the call to SetThemeCursor comes from the Finder’s own code. Hex offset 0x5123c into the Finder executable binary, to be precise.
If you run gdb from the Terminal and “attach Finder”, what happens if you set a breakpoint on SetThemeCursor, switch to the Finder, and hit the shift key?
September 2nd, 2005 at 9:45 pm
OK, maybe I need a bit of hand-holding here. :) I launched gdb, and issued the “attach Finder” command to gdb. It read the symbols for shared libraries, posted a “0x9000a778 in mach_msg_trap ()” line, but after this, I can’t do anything in the Finder (it just beachballs forever) until I detach the Finder from gdb by quitting gdb. (Issuing the “break SetThemeCursor” command doesn’t help — incidentally, though, it tells me I put a breakpoint at 0x931a87b8, instead of 0x5123c, but maybe those are different things.)
Help me out a bit here?
— Simone
September 2nd, 2005 at 9:48 pm
Sorry – I’ve been living and breathing gdb for so long I assume too much familiarity :)
Once you attach you’ve got Finder in your debugger, but it’s “stopped,” just as if you had hit a breakpoint. Whenever you’re in gdb and you want to start again, you can type “c” for continue and press return.
When you’re all done and you want your Finder back you can just type “quit” and agree to detach the Finder.
September 2nd, 2005 at 9:52 pm
Err.. so I figured out that it was just stopping at that breakpoint that it automatically added (?), but after issuing the “c” command, it continues reading symbols for a while and then just stops and doesn’t allow me to issue any more commands.
— Simone
September 2nd, 2005 at 9:53 pm
Err OK, got it. But now it just breaks as soon as I switch to the Finder at SetThemeCursor.
— Simone
September 2nd, 2005 at 9:57 pm
Oops – yeah it sets the cursor on activation as well as when modifier keys are pressed. So, a good trick for gdb when you just want to see that something happened without it interfering with your progress, it set a command for the breakpoint that automatically continues. After you’ve hit the SetThemeCursor breakpoint once, do this:
Breakpoint 1, 0x931a87b8 in SetThemeCursor ()
(gdb) command
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just “end”.
>print “hello”
>c
>end
(gdb) c
Continuing.
Breakpoint 1, 0x931a87b8 in SetThemeCursor ()
$1 = “hello”
I like to do the little ‘print “hello”‘ thing just to get gdb to advance a counter so I can tell that new breakpoints are being hit.
Are you having fun yet? :)
September 2nd, 2005 at 10:08 pm
Whee! Yes I am having fun. :) I don’t mind learning about nerdy things buried in Mac OS X.
ANYWAY, now that we got that gdb misunderstanding sorted out, we can get back to investigating the bug. When I switch to the Finder and press any modifier key, the counter does indeed increment, once when I depress the shift key, and once when I release it.
I took this a step further (just in case you were going to ask this as a follow-up :) ), and I opened up Dashboard and clicked in the text field. Pressing the shift key (or any other modifier key including the option key) does NOT increment the counter in gdb. Incidentally, something that may be related to the bug, is that the first time I switched into Dashboard, I didn’t get the I-beam cursor at all after clicking in the translation widget, and the shift-key had the same effect as when in the Finder. But after deactivating Dashboard and reactivating it once, I could again get the I-beam to show up after clicking in the translation widget’s text field, and then again, gdb’s counter would not increment when pressing a modifier key.
So perhaps it happens only in some instances? I’m curious, though — do you get the I-beam cursor AT ALL when you click on the translation widget in Dashboard, or does it show up and then get replaced when you press a modifier key?
Confused yet? :)
— Simone
September 2nd, 2005 at 10:10 pm
Hmm, perhaps this is the cause:
The bug seems to only manifest itself (as you noted in your post, and as I noted the first time I activated Dashboard) when you switch to Dashboard FROM THE FINDER. In this case, the gdb counter does increment when you depress a modifier key.
However, when you switch to Dashboard from some other application, the Finder doesn’t take over and you don’t get gdb counter increments.
So perhaps the bug you’re talking about only manifests itself when you switch directly to the app from the Finder, but not when you switch to it from some other application?
— Simone
September 2nd, 2005 at 10:15 pm
Yep – that’s it :) Glad to know that the bug reproduces for you after all.
The bug is that Finder interferes with UI elements that are “camping out” in its territory. Dashboard is just a convenient example, but there are many other apps out there displaying UI without actually becoming the “frontmost app”.
I feel that Apple should do something to prevent *any* app from interfering with legitimate UI that is being displayed atop another app, but if they won’t fix that bug, I’d at least like them to pull in the reigns on Finder’s overactive cursor setting.
Now if you happen to have an app on your system that you know was built in PowerPlant, switch to Dashboard from it, and what you’ll probably observe is that the I-beam cursor appears for a scant instant before being obliterated by the front-most app.
September 2nd, 2005 at 10:25 pm
Hmm, after re-reading your post, I see I missed the crucial step of the Finder needing to be the front-most app. *sheepish grin* I first read it thinking that the Finder would take over the cursor regardless of how you switched to the application or whatever. So it seems that this is just a bit of an oversight as to when the Finder switches cursors, rather than a more serious bug where the Finder really encroaches on everybody else’s cursors.
But obviously it’s a bug nonetheless. :) I agree, though, that applications should only be able to take over the cursor in certain situations, like when you’re hovering the mouse over that app’s UI.
— Simone
December 5th, 2005 at 11:08 pm
If i will run any of the application (including calculator, sol,…) in front of my C# application , My paint method is flickering more. How to solve this problem