More Make-Up Apple Bug Fridays
Thursday, 2005-12-29; 05:42:00
Tomorrow is another Friday, so its time for a few more make-up Apple Bug Fridays. Whee!
One quick note: turns out that the iChat bug that I reported here isn't actually a bug at all. Apple just eliminated the separate "Initiate one-way audio chat..." and "Initiate one-way video chat..." menu items in the Buddy menu. The green icons still don't show up in the buddy list for one-way chats, but the "Initiate audio chat..." and "Initiate video chat..." menu items change to their one-way counterparts when an appropriate buddy is selected. Oops! That means I'm doing a rerun of Apple Bug Friday XX, only it's still going to be original even though it's a rerun. :)
XX (rerun): iTunes 6.0.x scrubbing doesn't work when the iTunes window is in mini-mode. This is an intermittent bug, but it only happens in iTunes 6.0.x (and perhaps iTunes 5, but definitely not iTunes 4.x) when the iTunes window is in mini-mode.
Here's what happens. If you click-and-hold on the previous or next track buttons in the mini player, iTunes jumps five seconds in the appropriate direction after half a second. After that, though, the button automatically gets unclicked, and it doesn't scrub any more because the iTunes button isn't held down anymore (even though your finger is still holding down on the physical mouse button). So to scrub through tracks in this situation, you have to use the position indicator instead.
You can sometimes get this bug to go away; I got it to go away for a little bit by deleting my iTunes preferences, but the problem came back pretty soon after I did that while I was resetting my preferences to how I like it. It's an annoying bug because I do a lot of track scrubbing. Plus, the buttons are a much easier target than the the position indicator bar. Filed: 4394570
XXI: Another iTunes mini-mode bug: the mini player mode display sometimes changes to the "iPod synchronization is complete" display at random. No synching was done (as far as I can tell) -- the display just spontaneously changes. I can't find any rhyme or reason to it, but it's annoying because it completely takes over the mini display and doesn't allow me to see anything about the currently playing song. Grr! Filed: 4394575
XXII: This bug is a problem I've encountered when programming. When you add an NSTableColumn to an NSTableView programatically, the NSTableView (using the autosaveName) does not automatically update the saved column positions and sizes, so when you quit and reload the program, the column that you just added does not appear because it doesn't appear in the list of saved column positions/sizes.
There's a workaround to the problem: you need to use the setWidth: method to change the size of the column by a pixel (after adding the column), and then you need to set it back to its original width. The problem is, if you have a column that isn't supposed to be resizable, you have to use the setResizable: method to YES (which is actuallydepreciated deprecated in Tiger, but whatever), resize the column by a pixel and back, and then make the column unresizable again.
This problem has plagued Memory Usage Getter since version 2.1. Columns that I added programatically weren't always showing up when MUG was relaunched. It was so annoying, and I never really fixed the bug. However, today I realized that some of the columns I was using weren't resizable, which is why they weren't showing up after adding the column and quitting MUG. So I finally figured out the second part to the problem, which was that you have to set the column to be resizable and then resize it by a pixel, before the NSTableView automatically updates the column sizes/positions. So the forthcoming MUG 2.6 update will finally put this bug to rest. Grr. Bug filed: 4394583
XXIII: Front Row AppleScript bug: if you auto-activate Front Row via an AppleScript that uses UI scripting, it can cause all sorts of havoc on your Mac if that was the first time you activated Front Row after logging into your iMac. You can see the AppleScript by reading one of my weekly Question Time articles. The problems that the script causes are threefold (there may be more symptoms that I haven't found): the IR remote that controls Front Row stops working, the media keys (volume up/down/mute and media eject) on Apple Pro Keyboards stop working, and you're unable to log out. It's quite an annoying bug.
Apparently, there's also a secondary side effect if you activate Front Row using the method I used in the script: the Front Row Minimize Bug. You can see a description of that bug over at Andrew Escobar's site. He contacted me after I posted the script on AppleXnet. It doesn't have any affect on the script, but even if you use his updated script, it still causes the first part of the bug that I described. Hopefully this one'll be fixed soon. Filed: 4394612
[UPDATE: The first part of this bug can be fixed by not including the
Mmm... bugs.
One quick note: turns out that the iChat bug that I reported here isn't actually a bug at all. Apple just eliminated the separate "Initiate one-way audio chat..." and "Initiate one-way video chat..." menu items in the Buddy menu. The green icons still don't show up in the buddy list for one-way chats, but the "Initiate audio chat..." and "Initiate video chat..." menu items change to their one-way counterparts when an appropriate buddy is selected. Oops! That means I'm doing a rerun of Apple Bug Friday XX, only it's still going to be original even though it's a rerun. :)
XX (rerun): iTunes 6.0.x scrubbing doesn't work when the iTunes window is in mini-mode. This is an intermittent bug, but it only happens in iTunes 6.0.x (and perhaps iTunes 5, but definitely not iTunes 4.x) when the iTunes window is in mini-mode.
Here's what happens. If you click-and-hold on the previous or next track buttons in the mini player, iTunes jumps five seconds in the appropriate direction after half a second. After that, though, the button automatically gets unclicked, and it doesn't scrub any more because the iTunes button isn't held down anymore (even though your finger is still holding down on the physical mouse button). So to scrub through tracks in this situation, you have to use the position indicator instead.
You can sometimes get this bug to go away; I got it to go away for a little bit by deleting my iTunes preferences, but the problem came back pretty soon after I did that while I was resetting my preferences to how I like it. It's an annoying bug because I do a lot of track scrubbing. Plus, the buttons are a much easier target than the the position indicator bar. Filed: 4394570
XXI: Another iTunes mini-mode bug: the mini player mode display sometimes changes to the "iPod synchronization is complete" display at random. No synching was done (as far as I can tell) -- the display just spontaneously changes. I can't find any rhyme or reason to it, but it's annoying because it completely takes over the mini display and doesn't allow me to see anything about the currently playing song. Grr! Filed: 4394575
XXII: This bug is a problem I've encountered when programming. When you add an NSTableColumn to an NSTableView programatically, the NSTableView (using the autosaveName) does not automatically update the saved column positions and sizes, so when you quit and reload the program, the column that you just added does not appear because it doesn't appear in the list of saved column positions/sizes.
There's a workaround to the problem: you need to use the setWidth: method to change the size of the column by a pixel (after adding the column), and then you need to set it back to its original width. The problem is, if you have a column that isn't supposed to be resizable, you have to use the setResizable: method to YES (which is actually
This problem has plagued Memory Usage Getter since version 2.1. Columns that I added programatically weren't always showing up when MUG was relaunched. It was so annoying, and I never really fixed the bug. However, today I realized that some of the columns I was using weren't resizable, which is why they weren't showing up after adding the column and quitting MUG. So I finally figured out the second part to the problem, which was that you have to set the column to be resizable and then resize it by a pixel, before the NSTableView automatically updates the column sizes/positions. So the forthcoming MUG 2.6 update will finally put this bug to rest. Grr. Bug filed: 4394583
XXIII: Front Row AppleScript bug: if you auto-activate Front Row via an AppleScript that uses UI scripting, it can cause all sorts of havoc on your Mac if that was the first time you activated Front Row after logging into your iMac. You can see the AppleScript by reading one of my weekly Question Time articles. The problems that the script causes are threefold (there may be more symptoms that I haven't found): the IR remote that controls Front Row stops working, the media keys (volume up/down/mute and media eject) on Apple Pro Keyboards stop working, and you're unable to log out. It's quite an annoying bug.
Apparently, there's also a secondary side effect if you activate Front Row using the method I used in the script: the Front Row Minimize Bug. You can see a description of that bug over at Andrew Escobar's site. He contacted me after I posted the script on AppleXnet. It doesn't have any affect on the script, but even if you use his updated script, it still causes the first part of the bug that I described. Hopefully this one'll be fixed soon. Filed: 4394612
[UPDATE: The first part of this bug can be fixed by not including the
tell application "Front Row"/activate/end tell
lines in the script. However, this still should not happen, because the Front Row application is launched under your user, so even though it may have been launched by an AppleScript, a second instance of Front Row should not be initiated.]Mmm... bugs.
Technological Supernova Apple Bug Friday Older Newer Post a Comment