Login controls to remain onscreen when using SFAuthorizationPluginView.

Question

Created Apr ’25

Replies 2

Boosts 0

Participants 2

Regarding the issue of login controls remaining on screen for a few seconds when using a subclass of SFAuthorizationPluginView, I wanted to inquire whether any progress has been made on resolving it.

To recap, per notes I found in the QAuthPlugins sample code:

Due to a bug (FB12074874), the use of an SFAuthorizationPluginView subclass can cause the login controls to remain onscreen for a significant amount of time (roughly 5 seconds) after login is complete, resulting in them being onscreen at the same time as the Finder’s menu bar and the Dock. The exact circumstances under which this happens are not well understood, but one factor seems to be running on a laptop where the main display is mirrored to an external display.

Specifically, I would like to know:

If there any other information about how the issue is reproduced? For my part I can say that it reproduces with out the use of a mirrored display. So far it reproduces for all of our developers and testers, all of the time.
Are there any known workarounds?
Is there any expectation that this issue will be addressed?

Thank you so much!

Answered by DTS Engineer in 834069022

FB12074874 remains unresolved.

For my part I can say that it reproduces with out the use of a mirrored display. So far it reproduces for all of our developers and testers, all of the time.

In that case, I encourage you to file your own bug. The last time I looked at this, it was quite hard to reproduce.

Please post your bug number, just for the record.

On the workaround front, I’ve seen folks attempt various things but I’ve got nothing that I specifically recommend.

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

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’25

Recommended

FB12074874 remains unresolved.

For my part I can say that it reproduces with out the use of a mirrored display. So far it reproduces for all of our developers and testers, all of the time.

In that case, I encourage you to file your own bug. The last time I looked at this, it was quite hard to reproduce.

Please post your bug number, just for the record.

On the workaround front, I’ve seen folks attempt various things but I’ve got nothing that I specifically recommend.

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

0

Answer 2

khazelgren OP

Apr ’25

Sometimes reproducing the issue is 9/10ths of the battle, and since I am able to reproduce it consistently, I was able to gather information that led me to not only a workaround, but potentially the root cause. I have filed a bug FB17278823 and described my findings therein.

For the benefit of other developers I will describe my workaround here, but be warned that it may not be Apple Store safe (not an issue for me).

The issue as I found it relates to a dispatch call to CoreAnalytics when the plug-in is exiting. This call appears to be hardcoded for five seconds and blocks the main thread.

The workaround is to call _exit(0) after setting the result in the context (allow or deny), which will avoid the atexit handlers, including CoreAnalytics (this is the part that may not be Store safe).

Note: the call must be dispatched async to the main thread, which will allow processing of the credentials to continue.

        // Set Allow in the context
        let _ = <MyPluginName>.setResult(.allow, engine: self.engine, callbacks: self.plugin.callbacks)

        // Skips CoreAnalytics, avoiding the 5‑second hang
        DispatchQueue.main.async {
            _exit(0)
        }

0