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

Question

Created 19h

Replies 2

Boosts 0

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

2h

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

27m

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