macOS Sonoma Lock Screen with SFAutorizationPluginView is not hiding the macOS desktop

On Sonoma beta 7, if system.login.screensaver is updated to use authenticate-session-owner-or-admin, and then Lock Screen is not hiding the macOS Desktop.

Did you file a bug about this already? If so, please post the bug number. If not, file it now and post the bug number.

Is this a regression in 14.0b7? Or has it been that way for all the 14.0 betas?

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

HI Eskimo,

I have filed a bug on Aug 18th, as there is no update on the bug, I have posted this in the forums. Here is the bug : FB13000811 (Lock Screen with SFAutorizationPluginView(old UI) is not hiding the macOS desktop).

I have seen this issue on 14.0 beta 5 onwards, not sure of the earlier betas as I have not tried on them.

Thanks & Regards, Tata Chaitanya

Here is the bug : FB13000811

Thanks.

not sure of the earlier betas as I have not tried on them.

OK, lemme be clear: If you’re building an authorisation plug-in product, test with every beta that Apple seeds. This is especially important for major OS releases, like macOS 14, but it applies to minor updates as well. The authorisation plug-in API is super brittle, and if something is broken you need to report it early in the beta process.

As to what’s going on here, it’s hard to say. Normally I’d suggest that you open a DTS tech support incident for me to take a look, but I’m reluctant to do that now because my TSI queue is so full that I probably won’t get to your stuff for months )-:

Does the problem reproduce with QAuthPlugins?

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

Hi Eskimo,

Yes we are building authorization plugin and sure we will try to keep track of betas to verify our plugin.

But this issue is being observed without our plugin in place.

This should be reproduced with QAuthPlugins in place for screensaver. What I have followed is below:

On macOS Sonoma, Updated the system.login.screensaver to use “authenticate-session-owner-or-admin” We get the lock screen as below. Even after locking the machine you can see the Desktop in the background. (I have kept screensaver info in terminal and OS details open on desktop and performed Lock Screen).

This should be reproduced with QAuthPlugins in place for screensaver.

Cool. That simplifies things. Please update your bug with that info.

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

Hi Eskimo,

I have updated the bug **FB13000811 **(Lock Screen with SFAutorizationPluginView(old UI) is not hiding the macOS desktop).

As this issue is observed even without our product, Do you still want me to create a TSI request for this to check for a fix/solution?

Sonoma preview is going to be available from 26th September, so do you think this will be addressed before that or how will we take this up?

Thanks & Regards, Tata Chaitanya

Do you still want me to create a TSI request for this to check for a fix/solution?

As I mentioned above, I don’t think that’d be useful in this case.

so do you think this will be addressed before that

I can’t predict the future — not even the near future! — but:

• My general advice about release candidates builds is that they tend to be very close to the final release.

• You should plan accordingly.

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

Hi Eskimo,

Do we have any steps/script to bring a custom/black background to hide the Desktop, so till the time we get a fix by Apple, we will use this as a work around. Do you suggest any alternate work around which will help us here?

Thanks & Regards, Tata Chaitanya

Do you suggest any alternate work around which will help us here?

Nope. I have no leads as to how you might work around this. It’s something that Apple will have to fix.

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

Chiming in late, but I too filed FB12566615 on Jul 10 against Beta 3, and confirmed it was still present when I was asked if it was still a valid bug in the RC. I hope it gets fixed in the 14.1 release, even if the beta doesn't....

Alberto

I too filed FB12566615

Thanks.

Jul 10 against Beta 3

And thanks for filing it early. I think you might’ve been first, because your bug became the ‘lead’ bug for this issue.

I hope it gets fixed in the 14.1 release

FYI, the fix for this didn’t make it into 17.1b1 (23B5046f). As always, and especially with authorisation plug-ins, I recommend that you continue to re-test with new betas as they are seeded.

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

Hi Quinn,

As per the above conversation, I get Apple is working on a fix for this issue, is there any place where I can track the status as the bug I raised is still in Open state, and can we get informed here if a fix makes it to release? Is there any expected date?

Thanks & Regards,

Tata Chaitanya

is there any place where I can track the status as the bug I raised is still in Open state

Your bug (FB13000811) has been marked as a duplicate of ampm’s bug (FB12566615) so the bugs system should notify you when a fix starts seeding.

can we get informed here if a fix makes it to release? Is there any expected date?

No. See tip 3 in Quinn’s Top Ten DevForums Tips.

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

As always, and especially with authorisation plug-ins, I recommend that you continue to re-test with new betas as they are seeded.

We believe that this issue is resolved in 14.1b3. If you continue to have problems there, please let us know.

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

I’ve had a chance to dig into this in more detail and I have more specific advice.

macOS 14.0 has a bug (r. 112013559) where it fails to hide the user’s desktop when using a third-party authorization plug-in for screen unlock. This is reported as fixed in macOS 14.1b3 and later (including the current 14.1 release candidate).

Starting with macOS 14 we have new recommendations for folks with an authorisation plug-in that uses an SFAuthorizationPluginView subclass to override screen unlock:

• Tell your users to avoid macOS 14.0 because of the above-mentioned bug.

• Configure the system.login.screensaver right as you did previously.

• But also set the screenUnlockMode user default as follows:

  % sudo defaults write /Library/Preferences/com.apple.loginwindow screenUnlockMode -int 2
  

Our hope is that this will ensure better compatibility going forward.

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

Hi Quinn, what is the purpose of this setting? When I use it, the background of the user desktop behind the application windows turns white (instead of showing the wallpaper) and if I click on it all the windows are moved out of the visible space.

Thanks, Alberto