[Due for payment 2026-05-11] [$250] Android - SAML - Login page without email field opens after returning from SAML login page

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.60-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://github.com/Expensify/Expensify/issues/379028
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team
Device used: Samsung Galaxy S25 FE - Android 16, Celcom (TM TOUCH ) - Chrome

Action Performed:

Precondition:

• SAML requirement for login is enabled on OD.

1. Launch Expensify app.
2. Enter applausetester@applause.expensifail.com on email field.
3. Tap Continue.
4. Tap close button on the browser.

Expected Result:

App will return to login page with email field.

Actual Result:

App returns to login page with just animation without email field.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7110877_1774283469050.Screen_Recording_20260324_002729_Expensify.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022045149491033169998
• Upwork Job ID: 2045149491033169998
• Last Price Increase: 2026-04-24

[MelvinBot]

Proposal

What is the root cause of that problem?

When a SAML-required user closes the browser without completing login, SAMLSignInPage/index.native.tsx:82-83 calls Navigation.goBack() without clearing sign-in data. This leaves SignInPage in a dead state where:

• credentials.login is still set → shouldShowLoginForm = false (line 115)
• hasInitiatedSAMLLogin = true → shouldInitiateSAMLLogin = false (line 103)
• isSAMLRequired = true → shouldShowValidateCodeForm = false (line 127)
• The cleanup at line 109 requires !hasInitiatedSAMLLogin, which is false, so clearSignInData() never fires

No form is visible, so the user sees only the background animation.

What changes do you think we should make in order to solve the problem?

In SAMLSignInPage/index.native.tsx, call clearSignInData() before Navigation.goBack() when the user cancels the browser session (response type is not 'success'). This is the same pattern already used by the back button handler on lines 133-138 of the same file, and in the error path on lines 63-69. The same should be done in the .catch handler at line 90.

This resets credentials.login and account state so SignInPage correctly shows the login form again.

What alternative solutions did you explore? (Optional)

Modifying the cleanup condition in SignInPage.tsx (line 109) to also handle hasInitiatedSAMLLogin = true was considered, but that would be fragile — hasInitiatedSAMLLogin is React state local to SignInPage and won't survive unmount/remount. Clearing at the source (SAMLSignInPage) is more reliable and consistent with existing patterns in the same file.

Related issue

#86705 — also SAML-related login flow issue on mobile, though that one involves idle timeout rather than browser cancel.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @hoangzinh (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022045149491033169998

[skylarkerx]

1. Problem description

With SAML required for the domain (configured on OldDot), the user enters email, continues to SAML, then closes the Custom Tab / in-app browser instead of completing SSO. The app returns to the sign-in experience but shows only the hero / loading-style animation and no email field, so they cannot recover without restarting or other workarounds.

2. What is the root cause of that problem?

On native, when openAuthSessionAsync finishes without a successful redirect (response.type !== 'success', e.g. user dismisses Chrome Custom Tabs), the code only pops the SAML screen and does not clear sign-in state—unlike the explicit back affordance on the same screen.

That leaves credentials.login populated and SignInPage’s hasInitiatedSAMLLogin still true. For SAML-required accounts, getRenderOptions does not show the login form (shouldShowLoginForm requires !hasLogin) and excludes the magic-code path (!isSAMLRequired), so no primary form renders—only the layout/hero, matching “animation without email field.”

Dismiss / cancel path (no clearSignInData):

    useEffect(() => {
        // Don't open auth session more than once. If user cancels it we should navigate back to ROUTES.HOME
        if (!SAMLUrl || hasOpenedAuthSession.current) {
            return;
        }
        hasOpenedAuthSession.current = true;
        openAuthSessionAsync(SAMLUrl, CONST.SAML_REDIRECT_URL)
            .then((response: WebBrowserAuthSessionResult) => {
                if (response.type !== 'success') {
                    Navigation.goBack();
                    return;
                }
                handleNavigationStateChange(response.url);
            })
            .catch((error) => {
                Log.hmmm('SAML sign in failed', {error});
                Navigation.goBack();
            });
    }, [SAMLUrl, handleNavigationStateChange]);

Expensify/App: SAMLSignInPage/index.native.tsx (lines 74–91)

Back button (clears data, then goes back):

                <HeaderWithBackButton
                    title=""
                    onBackButtonPress={() => {
                        clearSignInData();
                        Navigation.isNavigationReady().then(() => {
                            Navigation.goBack();
                        });
                    }}
                />

Expensify/App: SAMLSignInPage/index.native.tsx (lines 131–138)

Why the login field disappears for SAML-required users:

    // True, if the user has SAML required, and we haven't yet initiated SAML for their account
    const shouldInitiateSAMLLogin = hasAccount && hasLogin && isSAMLRequired && !hasInitiatedSAMLLogin && !!account.isLoading;
    const shouldShowChooseSSOOrMagicCode = hasAccount && hasLogin && isSAMLEnabled && !isSAMLRequired && !isUsingMagicCode;
    // ...
    const shouldShowLoginForm = !shouldShowAnotherLoginPageOpenedMessage && !hasLogin && !hasValidateCode;
    // ...
    const shouldShowValidateCodeForm =
        !shouldShouldSignUpWelcomeForm &&
        hasAccount &&
        (hasLogin || hasValidateCode) &&
        !isUnvalidatedSecondaryLogin &&
        !hasEmailDeliveryFailure &&
        !hasSMSDeliveryFailure &&
        !shouldShowChooseSSOOrMagicCode &&
        !isSAMLRequired;

Expensify/App: SignInPage.tsx (lines 102–127)

3. What changes do you think we should make in order to solve the problem?

Align the dismiss / cancel / error paths with the header back behavior: clear partial sign-in state before leaving SAML_SIGN_IN so SignInPage can render the email step again (and the existing useEffect that resets hasInitiatedSAMLLogin when credentials.login is cleared can run).

Minimal patch (conceptual): in SAMLSignInPage/index.native.tsx, when response.type !== 'success' and in the .catch for openAuthSessionAsync, call clearSignInData() (already imported) before Navigation.goBack(), matching onBackButtonPress.

// Inside .then, non-success branch:
if (response.type !== 'success') {
    clearSignInData();
    Navigation.goBack();
    return;
}

// Inside .catch:
clearSignInData();
Navigation.goBack();

Optional hardening: merge Navigation.isNavigationReady().then(() => Navigation.goBack()) for parity with the back handler if ordering with Onyx updates ever races on some devices.

4. An alternative considered

Reset only UI state on SignInPage (e.g. force hasInitiatedSAMLLogin false when the SAML route unmounts or via a navigation listener) without clearing credentials. That avoids re-typing the email but requires a new explicit branch in getRenderOptions for “SAML required, session cancelled, show email or retry SSO”—more surface area and easier to regress. Clearing credentials matches the existing back-button contract and is the smallest fix.

[JustDreameritis]

🚨 Edited by proposal-police: This proposal was edited at 2026-04-17 14:50:25 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android, when a SAML-required user closes the browser during SAML login (without completing it), they return to the sign-in page showing only the background animation — no email input field is visible.

What is the root cause of that problem?

When the user cancels the auth session, SAMLSignInPage/index.native.tsx line 83 calls Navigation.goBack() without clearing sign-in data. This leaves credentials.login set in Onyx, so SignInPage computes shouldShowLoginForm = false (since hasLogin is true at line 115), while isSAMLRequired blocks all other forms too — resulting in a blank page. The cleanup guard at line 109 also does not fire because hasInitiatedSAMLLogin is true.

Additionally, both the cancel path (line 83) and the .catch handler (line 90) call Navigation.goBack() directly — without wrapping in Navigation.isNavigationReady(). Every other goBack call in this same file wraps it: the error handler at line 65 and the back button at line 135 both use isNavigationReady().then(() => goBack()). The unwrapped calls risk firing before navigation is ready after returning from the external browser.

What changes do you think we should make in order to solve the problem?

In SAMLSignInPage/index.native.tsx, add clearSignInData() and wrap goBack() in Navigation.isNavigationReady() for both the cancel and catch paths — matching the pattern already used elsewhere in the same file:

.then((response: WebBrowserAuthSessionResult) => {
    if (response.type !== 'success') {
        clearSignInData();
        Navigation.isNavigationReady().then(() => {
            Navigation.goBack();
        });
        return;
    }
    handleNavigationStateChange(response.url);
})
.catch((error) => {
    Log.hmmm('SAML sign in failed', {error});
    clearSignInData();
    Navigation.isNavigationReady().then(() => {
        Navigation.goBack();
    });
});

Single-file fix. clearSignInData() nulls ONYXKEYS.ACCOUNT, ONYXKEYS.CREDENTIALS, and HYBRID_APP.signingInWithSAML, so SignInPage re-renders with hasLogin = false and correctly shows the email input.

What alternative solutions did you explore? (Optional)

Modifying the cleanup condition in SignInPage.tsx (line 109) was considered, but hasInitiatedSAMLLogin is local React state that will not survive unmount/remount — clearing at the source in SAMLSignInPage is more reliable and consistent with the file's existing patterns.

[Nghondzweni]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android, when a SAML-required user is redirected to the browser to complete SSO login and then closes the browser (or presses back) without completing authentication, they are returned to the sign-in screen but see only the background animation — no email field, no form at all — and cannot proceed without restarting the app.

What is the root cause of that problem?

In src/pages/signin/SAMLSignInPage/index.native.tsx, when openAuthSessionAsync completes with anything other than 'success' (user cancelled, browser closed), the code calls Navigation.goBack() directly without first clearing sign-in state:

// Lines 82–84 (cancel path)
if (response.type !== 'success') {
    Navigation.goBack();
    return;
}

// Lines 88–90 (error/catch path)
.catch((error) => {
    Log.hmmm('SAML sign in failed', {error});
    Navigation.goBack();
});

Both paths leave credentials.login populated in Onyx. When SignInPage re-renders after the back navigation, all three form-rendering conditions evaluate to false:

• shouldShowLoginForm requires !hasLogin — false because credentials.login is still set
• shouldInitiateSAMLLogin requires !hasInitiatedSAMLLogin — false because it was already set to true
• shouldShowValidateCodeForm requires !isSAMLRequired — false for SAML-required accounts

No form is rendered, leaving the user with just the hero animation and no way to proceed.

The same file already handles this correctly in two other places: the back button handler at lines 134–136 calls clearSignInData() before Navigation.isNavigationReady().then(() => Navigation.goBack()), and the handleSAMLLoginError path at lines 63–67 does the same. The cancel and catch paths simply need to match this pattern.

What changes do you think we should make in order to solve the problem?

In src/pages/signin/SAMLSignInPage/index.native.tsx, update both the cancel path (non-success response) and the catch path to call clearSignInData() before navigating back, and wrap Navigation.goBack() in isNavigationReady().then() as is done elsewhere in the same file:

openAuthSessionAsync(SAMLUrl, CONST.SAML_REDIRECT_URL)
    .then((response: WebBrowserAuthSessionResult) => {
        if (response.type !== 'success') {
            clearSignInData();
            Navigation.isNavigationReady().then(() => {
                Navigation.goBack();
            });
            return;
        }
        handleNavigationStateChange(response.url);
    })
    .catch((error) => {
        Log.hmmm('SAML sign in failed', {error});
        clearSignInData();
        Navigation.isNavigationReady().then(() => {
            Navigation.goBack();
        });
    });

clearSignInData() nulls ONYXKEYS.CREDENTIALS, ONYXKEYS.ACCOUNT, and HYBRID_APP.signingInWithSAML in Onyx. After it runs, SignInPage re-evaluates with hasLogin = false and correctly shows the email input field.

This is a single-file change touching only the two broken paths. The back button and error paths are already correct and are unchanged.

What alternative solutions did you explore? (Optional)

An alternative would be to add a listener in SignInPage that detects when hasInitiatedSAMLLogin is still true but the SAML page is no longer in the navigation stack, and calls clearSignInData() reactively. This was rejected as more complex than needed — the cancel and catch paths in SAMLSignInPage are the correct place to reset state, and this is already the established pattern in the same file for the back button and error flows.

Contributor details
Expensify account email: trnghondzweni@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01d6ad2a62c32371cb

[melvin-bot]

@hoangzinh Whoops! This issue is 2 days overdue. Let's get this updated quick!