Take the code dialog down WITHOUT delivering a result, and put focus back where it came from.

abandonDialog, not cancelOpenDialog: we ARE the owner, and a result delivered back into this scope would re-enter the teardown we are in the middle of.

The re-focus is the part that is easy to miss. abandonDialog() removes the node and restores nothing — correct for its other callers, which are all onDestroy, where the view is going away and there is no focus to hand back. This screen STAYS ON THE AIR, and what comes next (the failure alert, or the save-credentials confirm) DERIVES its returnFocusTo from whatever holds focus at that instant. Measured on device: after an abandon that derivation collapses to the scene root, so dismissing the next dialog would hand focus to nothing. See the abandonDialog characterization in tests/source/unit/utils/dialogs.spec.bs.

Safe when no dialog is open: focus is already on the button row, so this is a no-op on the paths that fail before a dialog ever opens.

returnFocusToPicker is FALSE from onDestroy, and that is not a nicety: this view is being replaced, so re-focusing our own button row there could take focus off the view that replaces us. A destroyed view has nothing to hand focus back to, which is the case abandonDialog's no-restore behaviour is built for.

Apply splash background based on enabled flag Uses forceBackdrop parameter to show splashscreen before user login

Signed in, but nothing is persisted yet. Ask the same question LoginScene asks with its "save credentials" checkbox, in the standard confirm dialog — the app is holding a live session either way, so a cancel is a legitimate "no", not a failure.

Stop polling and drop the dialog + session state. Safe to call repeatedly, and safe to call with no flow in progress.

returnFocusToPicker is false for exactly one caller — onDestroy. See abandonQuickConnectDialog for why the two cases differ.

Approved: trade the secret for an access token.

Act on one poll outcome. The classification itself is pure and unit-tested — see quickConnectPollOutcome in source/utils/quickConnect.bs for the measured server behaviour behind it.

Load splashscreen if enabled on server Always fetches fresh branding config from server

Manual-login / Quick Connect buttons → intents the loginRouter coordinator handles.

onDestroy: Full teardown releasing all resources before component removal Called automatically via JRScreen.beforeViewClose when sgRouter permanently closes this view. Note: onScreenHidden already cleared the backdrop; this handles task/ref cleanup.

The user dismissed the code dialog. The only outcome it can produce on its own.

JRScreen hook called when the screen is hidden by the screen manager

JRScreen hook called when the screen is displayed by the screen manager

A user tile was picked. Resolve its id from the rendered list (UserRow fires the username), publish both, and emit the userSelected intent (was CreateUserSelectGroup returning the username to LoginFlow's public-user branch).

Show the code and start polling for approval.

Ask the server whether the code has been approved yet. Fires on the timer, so the request is never in flight twice.

Probe the server's /QuickConnect/Enabled endpoint and remove the QC button if the server reports it disabled. Render-thread promise (#551 Batch 1, 3b pattern) — replaces the former QuickConnectEnabledTask (createObject + observeFieldScoped on responseCode). Fail-open: only a definitive false removes the button; any non-ok HTTP response, transport failure, or timeout leaves it visible.

Remove the Quick Connect button and re-center the remaining buttons. Safe to call repeatedly - removeChild is a no-op once the node is detached.

Report a Quick Connect failure in the standard alert dialog.

The three reasons get three different messages because only one of them tells the user to stop: DISABLED means the server has the feature switched off, while UNAVAILABLE means try again shortly and SPENT means get a fresh code. The classification is pure and version-matrixed (source/utils/quickConnect.bs); this function only maps it to a string.

Presented AFTER endQuickConnect has taken the code dialog down, never over it: presentOverlayDialog supersedes an incumbent overlay, so showing the alert first would cancel the code dialog and re-enter onQuickConnectDialogResult.

Quick Connect pressed. Start a request and open the dialog once we have a code.