SFUnlock UI changes in macOS Golden Gate Beta – OK button requires double-click after password entry

We have observed significant UI changes to the SFUnlock login experience in the latest macOS Golden Gate Beta.

After entering the account password at the SFUnlock screen,user has to click on Use Password button once and then click on the OK button to proceed to the desktop and for the login process to continue successfully. This behaviour is consistently reproducible in our testing.

We would like to understand:

1.Is this a known issue with the current macOS Golden Gate Beta?

2.Is this expected behaviour due to the UI redesign, or is it considered a bug?

3.If it is a known issue, is there a fix planned for an upcoming beta or the final release?

Any information or guidance would be appreciated. Thank you.

Answered by DTS Engineer in 900882022

Thanks for confirming that.

IMO you should file a bug about this. It doesn’t really matter whether this is by design or not, because you have an existing product that’s having problems on the beta. So either:

  • If it’s by design, your bug report can act as a request to reconsider that design.
  • If not, it can act as a normal bug report.

Please post your bug number, just for the record.

As always, include a sysdiagnose log with your bug report, taken on the machine with the problem shortly after reproducing it. It’d also help if you attach screenshots of what you see on macOS 26 and what you see on macOS 27 beta.

I typically test this stuff on a VM, where it’s easy to get a screenshot by triggering it on the host. If your testing this on real hardware, you can SSH in and take a screenshot using the screencapture tool.

Share and Enjoy

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

I’d like to clarify what you mean by “SFUnlock UI”. There’s no SFUnlock symbol, so I suspect you’re using this as a shorthand for something. Are you talking about:

  • An authorisation plug-in
  • With a mechanism that you install into system.login.screensaver
  • That uses SFAuthorizationPluginView to present a custom UI to unlock the screen?

Share and Enjoy

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

Yes , I meant the SFAuthorizationPluginView of MAC. We are trying to authenticate-session-owner-or-admin in system.login.screensaver authorisation db.

Thanks for confirming that.

IMO you should file a bug about this. It doesn’t really matter whether this is by design or not, because you have an existing product that’s having problems on the beta. So either:

  • If it’s by design, your bug report can act as a request to reconsider that design.
  • If not, it can act as a normal bug report.

Please post your bug number, just for the record.

As always, include a sysdiagnose log with your bug report, taken on the machine with the problem shortly after reproducing it. It’d also help if you attach screenshots of what you see on macOS 26 and what you see on macOS 27 beta.

I typically test this stuff on a VM, where it’s easy to get a screenshot by triggering it on the host. If your testing this on real hardware, you can SSH in and take a screenshot using the screencapture tool.

Share and Enjoy

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

Thanks for the quick response.

We observed that this behavior was present in the native macOS SFAuthorizationPluginView in Beta 1. However, in Beta 5, the issue appears to occur only when a third-party authorization plugin is used. We are not seeing the same behavior with the native macOS SFAuthorizationPluginView.

Please find the attached screenshot showing the behavior with the native SFAuthorizationPluginView.

Could you please clarify why there is a difference in behavior between the native macOS SFAuthorizationPluginView and the same view when a third-party authorization plugin is integrated?

Our third-party plugins have not made any changes to, or taken any action on, the buttons displayed within the SFAuthorizationPluginView.

Is this a known change in Beta 5, or can we expect this behavior to be addressed in one of the upcoming beta releases?

Any clarification would be greatly appreciated.

oleksandr91 wrote:

I have also filed a bug about this issue: FB23959113

Thanks.

Would you be able to link it with the one created by the OP so that I also receive updates on the progress?

I would, but AFAICT PrathibhaD hasn’t yet filed a bug about this )-:


PrathibhaD, to reiterate my previous response, I don’t think you should burn cycles trying to determine whether this is or isn’t intended. It’s clearly an annoying behaviour change and that makes it bugworthy.

Keep in mind that we just released 27.0b6, so it’d be worthwhile testing on that before you file your bug (which is not to say that I have any evidence of this being fixed in 27.0b6).

And don’t forget to post your bug number, just for the record.

Share and Enjoy

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

I have raised a bug for the same. Please do find the reference for it https://feedbackassistant.apple.com/feedback/24396407. Can you kindly attach it to oleksandr91 bug so that we can get regular updates too.

Also, we have updated and tried in macOS 27 Beta 6 , but noticed that the issue is still reproducible.

Thanks for filing FB24396407.

Can you kindly attach it to oleksandr91 bug

Done. (That’s FB23959113 btw.)

so that we can get regular updates too.

Hmmm, that’s not how Feedback Assistant works. Unless we need more info from you, you’ll only receive an update if and when we start seeding an OS release with the fix.

Share and Enjoy

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

SFUnlock UI changes in macOS Golden Gate Beta – OK button requires double-click after password entry
 
 
Q