November 12th, 2014 • 10:26 am
OS X has a special keyboard mode that it switches to whenever the cursor is in a password field (in an OS X dialog, in a web page in Safari, Firefox, in apps that require password input, etc.). This mode, called ‘Secure Keyboard Mode’, is intended to protect your password input from any kind of snooping by other apps, so that your password remains secure.
In a normal configuration, you don’t really notice when OS X switches from regular keyboard input mode to secure keyboard mode or vice versa, because it’s something that takes place behind the scenes.
However, there are a number of OS X utilities that rely on the ability to monitor your keyboard typing and are therefore affected when OS X switches keyboard input modes like this. I use at least two of these apps myself: Keyboard Maestro and Typinator. The usability of these fantastic apps is totally dependent on their ability to monitor keyboard input, so secure keyboard mode definitely affects them.
Recently, I have noticed a new problem on my Mac Pro running OS X 10.9.5. Sometimes — usually in the morning, after I wake my machine from sleep and start working — I notice that my Keyboard Maestro macros and Typinator features do not work properly. Upon careful examination of my user interface, I notice this on the right-hand side of my menu bar:
The Typinator icon in the menu bar normally looks like this:
What does this alternate icon with the dots mean? Well, a click on the Typinator menu provides the answer:
The dots indicate that OS X is stuck in Secure Keyboard Mode (SKM). Normally, the switching in and out of SKM is handled automatically by OS X. As soon as you enter your password and press Return to exit the password field, OS X switches out of SKM. But sometimes it does not. As the Typinator dialog box explains, the normal trick to fix this situation is to quit the parent app of the password field that switched SKM on in the first place.
Typinator tries to help by telling you who the culprit likely is. In this particular case, it tells me it’s Safari.
The problem is that, after I quit Safari, the problem does not go away. So I try quitting other likely culprits, including Firefox, 1Password, etc. Still nothing. I try quitting and relaunching Typinator itself, to no avail. Nothing helps but a complete restart of the machine, which clears the problem.
After this happened to me a few times over the course of a couple of weeks, I decided that I had to try and do something about it. So I contacted the tech support service at Ergonis, the software company that produces Typinator. They were quite helpful, but still insisted that there was some other app causing this problem. I explained that I had not been able to identify a culprit.
Typically, I would wake my machine in the morning, start working, and then notice that something was wrong when I tried to use one of my Keyboard Maestro macros or Typinator features. The different icon that Typinator uses in the menu bar is not that noticeable, and I was not in the habit of keeping an eye on it constantly to determine exactly when it would change.
Since Ergonis thought that 1Password was a prime candidate, they even contacted the Agile Software developers themselves in order to discuss the situation. They also ended up adding a bit of code to Typinator for me that would cause it to play a special sound whenever SKM was turned on, and a different sound whenever it was turned off.
This worked great, in that it clearly indicated to me whenever SKM was turned on and then back off. But it also made me realize that there was one other context where SKM was turned on that I had not thought of: the login window when I woke my computer from sleep. (It’s configured to ask for my password after it’s been put to sleep.)
When I woke my machine in the morning, the special sound would play immediately. And then as soon as I entered my password, the sound indicating that SKM was off would play as well.
Except that sometimes it did not. Sometimes, on my machine at least, after I enter the password requested by OS X upon waking the machine, and OS X logs me in, it fails to switch back out of SKM. And sure enough, if I go to the Typinator alert about SKM right after this happens, the dialog actually correctly identifies the background process called
loginwindow as the culprit. For some reason, if I don’t check the dialog right away, Typinator ends up losing track of who the culprit app is, and becomes unhelpful by blaming another app that has nothing to do with it.
Of course, I cannot remember exactly when the problem started, but it’s definitely been in the past couple of months, so I suspect one of the more recent OS X updates.
Now, the problem is that, unlike standalone apps like Safari, 1Password, etc., you cannot quit the background process called
loginwindow. It’s constantly running once you log in, and the only way to force it to restart is to restart the entire computer (or possibly log out completely and then back in, which is almost as time-consuming).
I thought about it for a moment and then wondered if maybe, since it was obviously a glitch in
loginwindow, I could force it to snap out of it by going through the login window again. I tried using the Fast User Switching menu to switch to another user environment and back to my regular user environment in OS X, but that didn’t help.
Finally, I simply put the computer back to sleep and then woke it up again. It asked me for my password, and voilà: as soon as I entered my password, it logged me back in and this time it switched out of SKM.
So I had, if not a fix, at least a workaround! I gleefully fired an email to Ergonis outlining my findings and thanking them for helping me identify the source of the problem with the addition of the special sounds (which I will definitely keep on). And I confirmed that 1Password was not involved at all in the problem, that it was clearly a problem with OS X itself.
Since then (that was several weeks ago), I have only experienced the problem a couple of times, and the workaround worked each time.
This morning, however, after waking my computer, I experienced the glitch again. I put my display back to sleep (using a hot corner) and woke it back up, but this time it didn’t play the special sound that indicates that SKM is on. I entered my password and was able to log back in, but SKM stayed on. (I also noticed a couple of other glitches in the user interface, but I don’t know if they were related at all.)
I tried again, but this time putting the entire system to sleep (using the Apple menu).
But when I tried to wake the system up, the screen stayed dark, and I saw a few tiny streaks of dancing pixels across it, as well as the ominous Spinning Beach Ball of Death. This time, I had obviously hit a more severe manifestation of the same bug, and I had no choice but to do a hard reboot of the machine, cursing Apple for their inability to produce glitch-free software and wasting my time with length reboots. (Even with an SSD startup volume, it takes time to relaunch everything and especially to reload every open web page off the Internet.)
I am afraid that this is where I am at now. The bug with SKM is still there, unaddressed. There’s little point in submitting a bug report to Apple, as the problem is very intermittent, and there is no 100% reliable way of reproducing it. It just happens from time to time.
Hopefully, if it happens again in the future, the workaround described above will continue to work and will enable me to avoid having to reboot. But, as I have just experienced this morning, there might be something more sinister at work here, a more serious bug of which the SKM glitch is just the milder manifestation.
I will probably upgrade to Yosemite in the coming months, and we’ll see if the problem still exists in the new OS. The best that I can hope for at this point is that Apple has somehow accidentally, unwittingly fixed it in Yosemite by updating the
loginwindow process code. Who knows?