Report-an-Apple-Bug-Friday for September 9, 2005

It’s Friday again, meaning Mac developers world-wide should report at least a bug to Apple. By the time I’m done writing this entry, it will be Saturday, but I swear I started typing before!

In any case, before we get on to the actual bug, I wanted to remind everyone of something very important: report yourself the other RABF! Indeed, the more people report a specific bug, the more likely it is to be checked rapidly by the people at Apple. This is why the del.icio.us tag is so important for this to work – if everyone adds their RABF there, it will be a cinch for everyone to cross-report all the bugs.

With that said, on with the bug.


Summary

When performing a live search in Keychain Access, if you delete one of the result item, the items list does not update itself to reflect the deletion of that item. Odd behavior ensues, such as being able to inspect a secure note but not being able to read its content.

Steps to Reproduce

  1. Open Keychain Access
  2. Create a secure note, give it a title and some content.
  3. Use the search field with an expression that will match the secure note created above.
  4. Delete the secure note without interacting with the search field.
  5. Notice that the item doesn’t disappear from the content list as it should.

Expected Results

The deleted item should be removed from the content list immediately after deletion.

Actual Results

The deleted item remains in the content list until the search field’s expression is changed or cleared.

Regression

I have only tested this on one computer running Mac OS X 10.4.2, e.g. Keychain Access 271.

Notes

Radar #4251880

I made a small movie which exhibits this bug. It requires QuickTime 7, since obviously everyone should use H.264 now.

http://www.devklog.net/movies/keychain_bug.mov

I know the original idea of this whole apple bug Friday thing was to re-report he same bug over and over, but I’ve got to say I’m not sure it’s all that helpful. It would be great if there were some way to ‘vote’ for particular Radar number, but do we really need to take up some poor engineer’s time marking out a bunch of duplicate reports?

Yes, I’ve noticed this bug too. They’ve ruined Keychain Access in Tiger, as far as I’m concerned. An even bigger search bug is that it’s case-sensitive! I’ve had to re-name my keychain items with lower-case letters to compensate. Plus, I hate the info-panel UI. I much prefer Keychain Access in Panther.

Matt, I’ve actually talked with a few people at Apple, and reporting each others’ bugs is the way the go. The more a particular issue has reported bugs, the more seriously it is looked at because it is deemed statistically more important.

I know it’s not optimal – I agree with you that there should be a voting system of some sort to avoid duplicates. However, there is currently no other way.

Jeff, I think case sensitivity is a good thing as far as Keychain items are concerned. For instance, it could be very likely to have say an AFP server named Dolly and a different one named dolly (I don’t actually know if AFP is case sensitive, but you get the idea).

However, whether or not searching should be case sensitive is another matter.

Oh, incidentally, has anyone noticed that Keychain items aren’t searched by Spotlight?

Jean-Francois,

That’s what I was talking about, case-sensitive searching.