![]() Clicking an app in the Dock or selecting an app in Spotlight should be considered explicit user permission, which would allow the app to be brought forward.Apple should document the feature in its support pages.Is there a way to rescue this as a security feature without removing it? Yes, I think so. User confusion - expert user confusion, if I do say so myself - is a bug. It's a bug because I thought it was a bug! I've been using a Mac for 20 years, and I was utterly confused for months about this "feature", until I finally figured it out on my own.(This is even worse if you have "Show indicators for open applications" disabled in Dock System Preferences.) Indeed you might not even see the background app at all if the frontmost app's window covers the screen. There's no alert, notification, or visual indication to the user that macOS is intentionally backgrounding the app.There's no way that I'm aware of to disable this security theater.Backgrounding the app is annoying and inconvenient, because I'm launching the app in order to use it immediately.Apps that are already running are brought forward when I click them in the Dock, so why the difference?.Why isn't clicking an app in the Dock considered explicit permission to bring the app forward?.The intention may have been good, but the implementation is bad. I filed Feedback with Apple (FB9986784), and Apple engineering wrote a response: This is intentional since we can't know the user's reason for wanting secure text, we won't allow another application to pull itself forward without the user's explicit permission, because a launched application could accidentally get sent keystrokes that the user expected to go into Terminal.Īpple set my Feedback resolution to "Works as currently designed".Īlthough Apple considers this behavior to be a feature rather than a bug, I personally consider it to be a bug rather than a feature. After much debugging, I isolated the problem to the "Secure Keyboard Entry" setting in Terminal's main menu. Shortly after I updated to Monterey, I noticed that apps kept launching in the background if Terminal app was in the foreground. In retrospect, it turns out that I had encountered this behavior before in a slightly different situation. ![]() (Apparently Hammerspoon is a macOS automation tool. I searched the web for documentation of this behavior and didn't find much - nothing from Apple, sadly - but there was an interesting Stack Overflow question: "On Monterey, while NSSecureTextField has focus, Hammerspoon can no longer bring another app into foreground". I'm not sure what causes these few exceptions. Also oddly, it doesn't happen in App Store app if the focus is in the Password field of the "Sign In to App Store" dialog. Oddly, it doesn't happen if the focus is in the Notes field of a New Secure Note Item. It happens in Keychain Access itself, if you create a New Password Item and put the focus in the Password field. It happens in the Music and TV apps with the "Sign In to iTunes Store" dialog. This behavior happens in every web browser, e.g., Safari, Google Chrome, and Firefox. (Make sure the app isn't already running, otherwise it will be brought forward.) On Monterey, put the focus in the Password field and then launch an app from the Dock or from Spotlight. All apps, not just Keychain Access app.īelow is an example to illustrate. ![]() (How many times must I enter my Apple ID?) I finally realized yesterday that this coincidence was the cause! Whenever the keyboard focus is in a secure text field, Monterey launches apps in the background. ![]() I keep Keychain Access in my Dock and launch it from there, typically to copy a password and paste it into a form. For a long time afterward I thought there was a bug in Keychain Access app that causes it to randomly launch in the background, behind the active app. MacOS 12 Monterey doesn't support my 2014 MacBook Pro, so I bought a new MacBook Pro in April. MacOS Monterey unannounced security misfeature Articles index macOS Monterey unannounced security misfeature Jby Jeff Johnson
0 Comments
Leave a Reply. |