SFAuthorizationPluginView UI changes in macOS Golden Gate Beta – Unable to access the child elements and button controls using NSAccessibilityProtocol

Question

Created 3w

Replies 5

Boosts 1

Participants 2

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

After entering the account password at the SFAuthorizationPluginView screen, we were previously able to access the buttons and other child elements present in the SFAuthorizationPluginView using "accessibilityChildrenInNavigationOrder" . Currently the method returns that there are no child elements eventhough there are clearly child elements presents including apple's native Ok and Cancel buttons.This behaviour is consistently reproducible in our testing.

Steps to Reproduce

Configure and launch an unlock authorization plug-in using SFAuthorizationPluginView.
Display the authorization UI in unlock.
Enter the account password.
Wait for the authorization UI to finish transitioning to the authenticated state.
Query the SFAuthorizationPluginView accessibility hierarchy.
Specifically query accessibilityChildrenInNavigationOrder.
Observe that the method returns no child accessibility elements.
Inspect the UI visually or using Accessibility Inspector and observe that child controls are still present, including the native OK and Cancel buttons.

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 901981022

Is this … considered a bug?

I don’t consider this a bug.

In general, when you’re implementing a view that plugs in to an existing system view, we don’t support you rummaging around in the view hierarchy to find and manipulate the surrounding system views. Those views aren’t considered API. If there are tasks related to those views that the system wants you achieve, it’ll provide a dedicated API for that. For example, in SFAuthorizationPluginView the buttonPressed(_:) and setButton(_:enabled:) methods are the API for interacting with the related buttons.

Code that doesn’t follow this rule can run into compatibility problems as the system evolves. I regularly see this crop up when we move system UI components between processes. For example, code that rummaged around in the UIWebView view hierarchy broke when we moved to the out-of-process WKWebView.

I’m not sure what exactly happened with SFAuthorizationPluginView in macOS 27 beta, but I’m not surprised by the failure you’re seeing. This technique is simply not supported.

If you can explain why you’re doing this — that is, what high-level task you’re trying to achieve — I’ll be happy to offer specific advice on that.

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

Answer 1

DTS Engineer OP

Apple

3w

Recommended

Is this … considered a bug?

I don’t consider this a bug.

In general, when you’re implementing a view that plugs in to an existing system view, we don’t support you rummaging around in the view hierarchy to find and manipulate the surrounding system views. Those views aren’t considered API. If there are tasks related to those views that the system wants you achieve, it’ll provide a dedicated API for that. For example, in SFAuthorizationPluginView the buttonPressed(_:) and setButton(_:enabled:) methods are the API for interacting with the related buttons.

Code that doesn’t follow this rule can run into compatibility problems as the system evolves. I regularly see this crop up when we move system UI components between processes. For example, code that rummaged around in the UIWebView view hierarchy broke when we moved to the out-of-process WKWebView.

I’m not sure what exactly happened with SFAuthorizationPluginView in macOS 27 beta, but I’m not surprised by the failure you’re seeing. This technique is simply not supported.

If you can explain why you’re doing this — that is, what high-level task you’re trying to achieve — I’ll be happy to offer specific advice on that.

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

Answer 2

PrathibhaD OP

3w

We are trying to customise the macOS native SFAuthorizationPluginView as shared in the image below.

These are the points that we are trying to achieve and the reference text and image is attached as below,

We are trying to customise the lock icon into a customised logo. (Company logo with wifi icon)
We are trying to customise the button text and color from "Ok" to "Submit"
We have customised the text "You must enter a password to unlock your screen" to "OTP"
We have customised the text "Enter your password to continue with "macOS"" to "Customised Text"

All these were achievable upto macOS Tahoe and has been not possible since Golden Gate Beta 1 and the behaviour remains same on Beta 6 too.

Can you please suggest us if there are any approaches available to achieve these customisations? image (2).png

Answer 3

DTS Engineer OP

Apple

3w

I don’t think any of that is achievable in a support fashion with the current API. My only advice is that you file an enhancement request for those features.

Please post your bug number, just for the record.

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

Answer 4

PrathibhaD OP

3w

I have raised an enhancement request as suggested, please do find the reference here https://feedbackassistant.apple.com/feedback/24412830 .

As this worked upto Tahoe, can you kindly help us to understand if this is an intentional change made to SFAuthorizationPluginView in macOS 27 Beta?

Answer 5

DTS Engineer OP

Apple

3w

Thanks for filing FB24412830.

As this worked upto Tahoe …

Right, but that’s only because it was relying on implementation details. We don’t support folks navigating the view hierarchy in order to manipulate system views. So, when you ask about “intentional change” you need to consider what actually changed. The supported API hasn’t changed here. Rather, we’ve changed a bunch of implementation details. Was that intentional? Clearly. Was the intention to break your product? Probably not (although it’s not like I’d admit that if it were :-).

My best guess is that these views have moved to a different process. Way back in the day macOS gained support for remote views, that is, a view that looks like it’s in an app’s window but is actually hosted in a completely different process. The canonical example of this is Powerbox, where we host the standard file open and save views in a separate process so that they can see the whole file system even when the app is sandboxed [1].

Over the years we’ve rolled this feature out in many different subsystems, with specific focus on security-sensitive subsystems. Hence my guess.

However, that is just a guess. The exact view hierarchy is an implementation detail and my role here is to help folks with APIs, not explain every implementation detail change. And the API story here is very clear.

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

[1] We actually discussed this in the old App Sandbox Design Guide document. That’s no longer available from Apple, but you can find copies of it elsewhere (see App Sandbox Resources).