Spotlight in Mac OS X 10.5 (Leopard): Further evidence of buggy behaviour in search results window

Posted by Pierre Igot in: Macintosh
February 29th, 2008 • 3:52 pm

As a follow-up to yesterday’s post about bugs in the Spotlight search results window in the Finder, here is a screen shot that I was able to capture today and provides further evidence that something is indeed quite wrong with the search results window:

Editable name in background

There is something very wrong with this picture. What is it? In a nutshell, it is that there is an editable file name in a background window. This is completely wrong. Normally, when you make a file name editable in the foreground window in the Finder, as soon as you switch to another window (either in the Finder or in another application) and the Finder window in question becomes a background window, the file name ceases to be editable. The Finder automatically exits the “editable file name” mode.

Yet, as you can see in the picture above, quite obviously when browsing search results in a Finder window in list view, sometimes when you double-click on a file to open it in its parent application, the double-click also has the unintended (and highly undesirable) effect of making the item’s name editable. And what is worse is that the name remains editable even once the Finder window in question has been relegated to the background by the opening of the file in question in its parent application.

In this particular case, the problem happened with a Spell Catcher glossary file. It was part of my search results and I double-clicked on it in order to open and edit it in Spell Catcher itself. The Finder window with the search results was relegated to the background, as expected, but I certainly did not do anything to cause it to make the name editable (I just double-clicked on the file to open it), and the name should definitely not have remained editable in the background.

As indicated yesterday, I strongly suspect that this has more than a little to do with the apparently random renaming of files/folders that can occur when working with search results in a Finder window. In fact, the same problem happened to me again this morning (with yet another list of search results), and this time I was able to confirm that the random renaming actually affects another item in the same list of search results.

In other words, what happens is that I have a list of search results in a Finder window. I double-click on some of the search results to open them in their parent applications, and then at some point one of the items in the list of search results takes on the name of another item in that same list of search results.

Since search results are typically scattered throughout your entire hard drive, it is really hard to keep track of this and notice it when the problem does happen.

And since double-clicking on an item in a list of search results typically opens a new window in front of the list of search results, thereby masking it temporarily, it is also hard to see what takes place in the background while you are examining your document window in the foreground.

Thanks to my fairly large screen real estate, I am able to see more than most users might be able to see, and with the example above I clearly saw that the file name became editable in the background window. Again, I strongly suspect that this has more than a little to do with the fact that the Finder “accidentally” renames items behind the user’s back.

Unfortunately, I still do not have a reliable way to reproduce this. I don’t have a reliable way to cause the Finder to make the item’s name editable in the background (yet it happens, as the screen shot above shows), and I don’t have a reliable way to cause the Finder to rename the item without my consent. Yet it most definitely happens—and I have more than enough reason to think that the two are very much linked.


Comments are closed.

Leave a Reply

Comments are closed.