Finder Drops Keystrokes After Creating New Folder
In practical terms, it means that, after I press command-shift-N on my machine (a 2014 Mac Pro with 32 GB of RAM, with a 1 TB SSD as the startup volume), I cannot start typing the name right away. I have to wait for a fraction of a second before I do so. If I don’t, then the first couple of letters I type fail to appear in the folder name that I typed.
Yes, you read this right: I, Pierre Igot, am a supernaturally fast typist, with whom a powerful machine such as the 2014 Mac Pro is not able to keep up.
[…]
What is really unbelievable to me here is not so much that the Finder needs a fraction of a second after creating the folder. It is that there does not seem to be any kind of text input buffer that keeps my keystrokes in memory until the OS is ready to process them. The keystroke(s) that the Finder fails to register simply disappear into the ether, as if the characters had never been typed.
This is the sort of thing that “just worked” 25 years ago with the classic Finder, but it has been broken for so long in Mac OS X that there must already be lots of duplicate Radars. It works in most other places, though. In Mail, I can start typing an address after creating a new message. In Safari, I can type a search query or URL after creating a new window. I did not have to do anything special to make it work in EagleFiler when creating new folders or files.
I can only guess that the Finder’s folder creation is very asynchronous so that it continues processing events before the folder has been created. So the keys arrive before there is a text field for them to go to. But, at least on my Mac, they don’t go into the ether. They go towards type-selection in the current window. So, for example, if I create a new folder and type “foo”, the Finder selects the first file in the list whose name begins with “f”, and then it creates the new folder, selects it, and types “oo” for the name.
Update (2016-03-28): Vegar Nilsen:
I see the same thing fairly regularly with Spotlight, where it e.g. only captures “witter”, and can’t understand which app I wanted.
Update (2016-03-30): To clarify, I never see the issue in Icons view, only in the List and Columns views.
13 Comments RSS · Twitter
"This is the sort of thing that “just worked” 25 years ago with the classic Finder, but it has been broken for so long in Mac OS X that there must already be lots of duplicate Radars."
FWIW, like most broken things in OS X, it's not a problem in Snow Leopard...
(Not even a problem when creating a new folder on a slow networked volume).
I'm not seeing that all, on a 2014 retina iMac, or on a 12" MacBook. I suspect some third-party software causing the delay.
I've seen a number of places (particularly iTunes) where async setup bites the user. You can, on slower boxes, get a few actions seemingly completed, only to have the OS "catch back up" a few seconds later, undoing your work. Muscle memory comes back to bite you too often.
Mishandled async calls drive me crazy, and I appreciate the problem getting some attention here.
"I'm not seeing that all, on a 2014 retina iMac, or on a 12" MacBook. I suspect some third-party software causing the delay."
When I initially read Pierre's post, I assumed it was just the horrible software support Apple was providing for the Mac Pro, which he's written about extensively in the past.
But then Michael's confirmation made me assume it was a universal problem. However, if you're not seeing it at all, the picture muddies.
(Someone who is experiencing the problem, and has time to waste, should do a wipe 'n' clean install to see if it really is 3rd party software.)
@Kirk @Chucky It happens for me in VMware with a clean installation of 10.11. (BTW, unless I type them really slowly, it also loses the first few characters of my password when booting my Mac. That may be a Bluetooth issue, though.)
I traced the problem to network activity occurring when using spotlight, so I turn off Bing Web Searches, Bookmarks & History, and Spotlight Suggestions which fixed lost keystrokes. This also fixed lost keystrokes in the finder for me as well.
I'm a fast typist (~110wpm) and found that I can get this to happen occasionally in a finder window, but not on the desktop. This on a 2014 mac mini (though I've got 14 years of OS X experience and another 5 of NeXTSTEP). But I'd never noticed the issue until I read this post. I hate to ask a stupid question, but has this been filed as a radar? It's absolutely the sort of thing I could imagine folks at Apple not having noticed, if I managed to go 14 years without seeing it.
I have this same issue consistently when creating folders in the Finder (mid-2013 MacBook Air). It's been bugging me for a little while.
In the same vein, I had an issue where, when selecting text with the mouse, I would often have the first few characters of my intended selection not being selected. I would chalk it up to me actually pressing the mouse button later than when I thought I did, since I click and very quickly move right. But it kept happening and nagging at me, until I tried a test:
- click, but not move the mouse at all (not even a pixel) for one second
- suddenly move the mouse to the left
That consistently reproduced the issue.
I did not even think such a crude procedure would reproduce the issue (e.g. it would not have if the delay simply began with the start of the click), and yet it did.
More interestingly: I could not reproduce the issue with iTunes (this was pre-Lion).
I filed a radar with these informations, it was not closed as a duplicate, and pretty quickly after that (well, as far as software updates go, of course), I stopped being able to reproduce the problem in any app. So definitely do file radars, it seems we are more attentive to this stuff than even the Apple guys are.
Personally, I blame Cocoa, or at least the relevant parts of Cocoa for these kind of less-than-perfectly-engineered evanescent iteraction issues; this explains why we saw those more and more, just as Carbon-based app were fading away.
"Personally, I blame Cocoa, or at least the relevant parts of Cocoa for these kind of less-than-perfectly-engineered evanescent iteraction issues; this explains why we saw those more and more, just as Carbon-based app were fading away."
Coherent theory that explains why none of this is an issue with Snow Leopard...
@ Kirk McElhearn: I am able to reproduce this in a separate user environment with no third-party software running.
As my blog post indicates, you need to go really fast to reproduce it manually (less than 0.3 s between shortcut and name typing). But the ultimate proof is to run the Keyboard Maestro, which reproduces the manual steps at very high speed. It'd be interesting to check if you can reproduce it with Keyboard Maestro on your systems.
