SFAuthorizationPluginView password field does not accept keyboard input until click on macOS Tahoe 26.4.1

Question

Created 1w

Replies 3

Boosts 1

Participants 3

We are using an SFAuthorizationPluginView-based authentication plug-in for screen unlock, and we are seeing focus/activation behavior on macOS Tahoe 26.4.1 that appears different from earlier macOS releases.

In our lock-screen plug-in UI, the view is displayed correctly, but keyboard input does not go to our password field until the user physically clicks inside the plug-in view.

We have already tried the documented focus-related hooks and standard AppKit approaches, including:

Overriding firstResponder
Overriding firstKeyView / lastKeyView
Calling becomeFirstResponder
Calling makeFirstResponder on the host window during activation
Setting up the key view loop between controls

Despite this, on Tahoe 26.4.1 the password field still does not accept typing until the first mouse click inside the plug-in view.

Could you clarify the following:

On macOS Tahoe 26.4.1, are there any known changes in SecurityAgent / SFAuthorizationPluginView behavior that affect firstResponder, firstKeyView, or keyboard activation during screen unlock?
Is a physical click now required before keyboard input is delivered to an SFAuthorizationPluginView in this context?
If not, what is the recommended supported way to ensure the password field becomes keyboard-active immediately when the plug-in view is shown?
Are becomeFirstResponder / makeFirstResponder expected to work in this host context, or are only the SFAuthorizationPluginView hooks (firstResponder, firstKeyView, lastKeyView) supported?
Is there any recommended host-window or activation API for this scenario, or is this considered a regression in Tahoe?

Boost

Answer 1

DTS Engineer OP

Apple

1w

appears different from earlier macOS releases.

What OS releases are you talking about here? Different from 26.4? From 26.3? From 26 itself? Or from macOS 15?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

oleksandr91 OP

2d

We are also facing this issue. To reproduce it, you don’t even need an authorization plugin; it is sufficient to replace use-login-window-ui with authenticate-session-owner in system.login.screensaver rule. On macOS 26.3 and prior, the window “You must enter a password to unlock the screen” is the key window, the password text field is focused, and you can enter the password and press Return to unlock or press Esc to dismiss the window. On macOS 26.4, 26.4.1, and 26.5 Beta 4, that window is no longer the key window, the password text field is not in focus, and pressing Return or Esc does nothing. I filed a feedback on an unrelated issue which also involved changing use-login-window-ui to authenticate-session-owner (FB22289735) and Apple said that this is unsupported configuration, but even then, surely this issue is a regression that should be addressed?

I must say that with the number of issues it caused (Calling SecKeychainUnlock with a locked keychain and an invalid password returns errSecSuccess on macOS 26.4/FB22627354; FB22657681 — a PAM module breaking the keychain, which took some three weeks of digging; the lock screen being shown up twice — we have that too, by the way; this issue), macOS 26.4 has been damaging to our product.

0

Answer 3

DTS Engineer OP

Apple

1d

Thanks for sharing your experience here.

Apple said that this is unsupported configuration

I read through the comments in FB22289735 and those were about the specific configuration covered by that bug. If this regression is causing problems for an actual product, I recommend that you file a bug focused on that. You can then use QAuthPlugins as evidence that this problem isn’t being caused by your code.

Please post your bug number, just for the record.

macOS 26.4 has been damaging to our product.

Bummer.

Unfortunately I don’t have any encouraging words here. Authorisation plug-ins are brittle; it’s not uncommon for them to break even with minor updates to macOS. I don’t imagine that changing unless there’s a significant reworking of this part of the OS. That’s why it’s so important to test your products with every macOS beta build that we seed. (I know you already do this, but I wanted to make sure that anonymoussingh understands this requirement.)

Also, if your product is deployed to enterprise environments it makes sense to encourage your largest customers to also do this testing, file their own bugs, or have you file the bug and give them the bug number, and then escalate any significant issues to their Apple Support contacts.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0