fix: App back button loops between employee step and verify email step by nkdengineer · Pull Request #93399 · Expensify/App

nkdengineer · 2026-06-12T08:53:55Z

Explanation of Change

fix: App back button loops between employee step and verify email step

Fixed Issues

$ #92688
PROPOSAL: #92688 (comment)

Tests

Precondition:

Sign out of ND and OD.

Go to staging.expensify.com
Select 1-9 employees and sign up with new Gmail account.
On another browser, or on Android/iOS app, log in to staging.new.expensify.com with the same Gmail account.
Verify that the employee step is displayed without the back button

Verify that no errors appear in the JS console

Offline tests

QA Steps

Same as test

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Screen.Recording.2026-06-12.at.15.46.46.mov

Android: mWeb Chrome

Screen.Recording.2026-06-12.at.15.44.42.mov

iOS: Native

Screen.Recording.2026-06-12.at.15.50.14.mov

iOS: mWeb Safari

Screen.Recording.2026-06-12.at.15.41.37.mov

MacOS: Chrome / Safari

Screen.Recording.2026-06-12.at.15.40.27.mov

melvin-bot · 2026-06-12T09:05:03Z

@ahmedGaber93 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

arekm213 · 2026-06-12T17:29:53Z

🧪 Mobile QA — before/after on `main` vs this PR

Verdict: ✅ PASS on both reported platforms (iOS App + Android App).

Reproduced the bug on main and confirmed the fix on this PR branch (fix/92688, commit ee86d699), on real simulators/emulators via Argent.

Context

Issue: #92688 — Onboarding - App back button loops between employee step and verify email step
Platforms reproduced (from the issue): Android: App ✅ · iOS: App ✅ (both tested below).
Exact element under test: the header back button on the Onboarding Employees screen (BaseOnboardingEmployees.tsx → HeaderWithBackButton shouldShowBackButton={!isEmployeesFirstStep}), plus the onboarding step counter / progress bar.
Repro condition: a public-domain (Gmail), validated, VSB account (signed up via the "1‑9 employees" landing flow) that lands on the Employees step.
Expected vs Actual:
- Actual (main): back button is shown on Employees → pressing it goes to "Verify your work email", which force-forwards back to Employees → an inescapable loop.
- Expected (fix): on a validated account, Employees is the first step → back button hidden → loop broken.
What the diff does: excludes the work‑email prefix from the onboarding flow when the account is validated (getDomainPrefix now checks isAccountValidated before the merge branch), and passes isAccountValidated into BaseOnboardingEmployees' flow context. So the VSB/SMB flow becomes [EMPLOYEES, ACCOUNTING, INTERESTED_FEATURES] → Employees = step 1 of 3 → back hidden.
Files: src/libs/getOnboardingStepCounter.ts, src/hooks/useOnboardingStepCounter.ts, src/pages/OnboardingEmployees/BaseOnboardingEmployees.tsx, tests/unit/getOnboardingStepCounterTest.ts.

Environment & method (please read — repro deviation noted)

Devices: iPhone 16 Pro Max (iOS 26) · Pixel 9 (Android 15, API 35). Account: expensifytestinglogin(+pr93200)@gmail.com (Gmail = public domain), staging.
The issue's precondition is an OldDot (staging.expensify.com) "1‑9 employees" signup, which sets signupQualifier = "vsb" server‑side, plus a validated account. That web signup isn't drivable in this mobile‑only harness, so I reproduced the exact same client state the OldDot signup produces, via an Onyx override applied identically to main and the PR branch:
- nvp_onboarding.signupQualifier = "vsb", hasCompletedGuidedSetupFlow = false (to enter the onboarding flow), isMergeAccountStepSkipped left unset (so back lands on "Verify your work email", matching the issue's exact loop), onboardingPurposeSelected = "newDotManageTeam".
- account.validated = true — genuinely true on the iOS account; injected on Android (its +tag account was unvalidated).
- account.isFromPublicDomain = true — genuinely true (Gmail) on both.
This is faithful because the back‑button / step‑counter logic under test is a pure client‑side function of (isFromPublicDomain, validated, signupQualifier, isMergeAccountStepSkipped) — there is no backend in the loop. Entry to the Employees screen was via the in‑app deep link new-expensify://onboarding/employees.

iOS App

Before — `main` (🐞 bug)

Employees screen shows a back button (<); pressing it goes to "Verify your work email", which bounces back to Employees → endless loop.

Employees — back button shown	Back → "Verify your work email" (loop)

Loop (Employees → Verify your work email → back into work‑email steps → Employees …):

▶️ Full video — ~40s, the loop with lead-in & aftermath context (compressed)

After — PR branch (✅ fixed)

Same injected state → Employees is now step 1, back button is gone (the HeaderWithBackButton no longer renders a Back pressable — confirmed in the component tree). No way to loop into the work‑email step.

Forward flow proves the fix: Employees (step 1/3, no back) → Continue → "Do you use any accounting software?" (step 2/3 — a back button now correctly appears) → tap back → returns to Employees (step 1/3, no back) — not "Verify your work email". The loop is gone.

▶️ Full video — ~46s, the corrected flow exercised 3× with context (compressed)

Android App

Before — `main` (🐞 bug)

Accessibility tree explicitly reports "Onboarding progress, Step 3 of 5" and a Button "Back" is present; pressing it goes to "Verify your work email" → loop.

Employees — "Step 3 of 5", back button shown	Back → "Verify your work email" (loop)

Loop (Employees ↔ Verify your work email):

▶️ Full video — ~45s, the loop with lead-in & aftermath context (compressed)

After — PR branch (✅ fixed)

Accessibility tree now reports "Onboarding progress, Step 1 of 3" and no Back button exists in the tree. Loop broken.

Forward flow proves the fix: Employees (step 1/3, no back) → Continue → "Do you use any accounting software?" (step 2/3 — a back button now correctly appears) → tap back → returns to Employees (step 1/3, no back) — not "Verify your work email". The loop is gone.

▶️ Full video — ~33s, the corrected flow exercised 3× with context (compressed)

Result

Platform	`main` (before)	PR (after)
iOS App	back button shown · loops Employees ↔ Verify work email	no back button · step 1 of 3	✅ PASS
Android App	"Step 3 of 5" · back button shown · loops	"Step 1 of 3" · no back button	✅ PASS

The PR resolves the reported behavior on both platforms: on a validated public‑domain VSB account, the Employees step becomes step 1 of 3 and the back button that caused the Employees ↔ "Verify your work email" loop is correctly hidden.

Caveat: as noted above, the OldDot‑sourced signupQualifier="vsb" (+ validated on Android) was applied via an Onyx override identical on both branches, since the OldDot web signup can't be driven in a mobile‑only harness. The logic under test is purely client‑side, so this faithfully reproduces the issue. The inline GIFs are trimmed to the key action for quick viewing; each ▶️ Full video link is the longer ~33–46s clip showing the repro with ~lead‑in and aftermath context (compressed ~540px).

_{🤖 Automated mobile QA run (Argent) — reproduced on main, verified on the PR branch, iOS + Android.}

ahmedGaber93 · 2026-06-13T19:31:12Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
- I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
- I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
- I verified the JSDocs style guidelines (in STYLE.md) were followed
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

a.mov

Android: mWeb Chrome

aw.mov

iOS: HybridApp

i.mov

iOS: mWeb Safari

MacOS: Chrome / Safari

Screen.Recording.2026-06-13.at.10.34.12.PM.mov

ahmedGaber93 · 2026-06-13T20:14:15Z

@nkdengineer Are those bugs is a regression from this PR?

Screen.Recording.2026-06-13.at.10.23.46.PM.mov

bug-ios.mov

nkdengineer · 2026-06-15T09:27:09Z

@ahmedGaber93 The employee step now is the first step, and can't go back to the work email step as this is skipped.

ahmedGaber93 · 2026-06-15T12:35:59Z

@nkdengineer, while those bugs don’t appear to be regressions from this PR, I believe we should address the Android bug since we handle the back behavior here.

Should we block the Android hardwareBackPress when isEmployeesFirstStep is true?

We have similar cases here:

App/src/pages/OnboardingPurpose/index.native.tsx

Lines 9 to 18 in a3a0005

    
           useFocusEffect( 
        
               useCallback(() => { 
        
                   // Return true to indicate that the back button press is handled here 
        
                   const backAction = () => true; 
        
                   const backHandler = BackHandler.addEventListener('hardwareBackPress', backAction); 
        
                   return () => backHandler.remove(); 
        
               }, []), 
        
           );

App/src/pages/OnboardingWorkEmail/index.native.tsx

Lines 10 to 22 in a3a0005

    
           useFocusEffect( 
        
               useCallback(() => { 
        
                   // Return true to indicate that the back button press is handled here 
        
                   const backAction = () => { 
        
                       setOnboardingErrorMessage('onboarding.purpose.errorBackButton'); 
        
                       return true; 
        
                   }; 
        
                   const backHandler = BackHandler.addEventListener('hardwareBackPress', backAction); 
        
                   return () => backHandler.remove(); 
        
               }, []), 
        
           );

App/src/pages/OnboardingPersonalDetails/index.native.tsx

Lines 10 to 25 in a3a0005

    
           // To block android native back button behavior 
        
           useFocusEffect( 
        
               useCallback(() => { 
        
                   // We don't want to block the back button if this is not the first route 
        
                   if (routeIndex !== 0) { 
        
                       return; 
        
                   } 
        
                   // Return true to indicate that the back button press is handled here 
        
                   const backAction = () => true; 
        
                   const backHandler = BackHandler.addEventListener('hardwareBackPress', backAction); 
        
                   return () => backHandler.remove(); 
        
               }, [routeIndex]), 
        
           );

nkdengineer · 2026-06-16T13:46:20Z

@ahmedGaber93 Makes sense. I updated.

neil-marcellini

Thanks, looks good

neil-marcellini · 2026-06-22T19:04:10Z

The C+ already posted a checklist and approved, so pasting one here just to pass it.

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

github-actions · 2026-06-22T19:09:09Z

🚧 @neil-marcellini has triggered a test Expensify/App build. You can view the workflow run here.

OSBotify · 2026-06-22T19:12:41Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

github-actions · 2026-06-22T19:16:34Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #93399.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-b3d324e4068-f22865b-e22f2a6394e7a914e77b252e975bc7c61e16d28d/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-b3d324e-f22865b-3b78fec9a8e8833e4780f23bab9b58bb3434edd7/index.html

Web 🕸️
https://93399.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

OSBotify · 2026-06-22T23:27:02Z

🚀 Deployed to staging by https://github.com/neil-marcellini in version: 9.4.17-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

Android
iOS

MelvinBot · 2026-06-22T23:28:39Z

🤖 Help site review: no changes required.

This PR fixes an internal navigation bug — the back button looping between the employees step and the verify-email step during onboarding — and corrects the onboarding step counter for accounts with a validated work email. The changes are limited to navigation/step-counter logic and a native Android back-button handler:

src/libs/getOnboardingStepCounter.ts / src/hooks/useOnboardingStepCounter.ts — exclude validated/skipped work-email steps from the flow
src/pages/OnboardingEmployees/* — block the dead back button on the first step
tests/unit/getOnboardingStepCounterTest.ts — coverage for the new cases

None of this changes a documented, user-facing feature, label, setting, or how-to. I searched App/docs/articles and there is no help-site article documenting the signup onboarding step navigation or back-button behavior (the only onboarding mentions are incidental references in unrelated articles like Expensify Home Overview). The user-visible onboarding flow itself is unchanged — this only repairs broken back-navigation — so no help-site updates are needed and I have not opened a draft PR.

@nkdengineer, since no help-site changes are required here, there is no linked help site PR to review. If you believe an onboarding article should be added or updated, let me know and I'll create a draft PR.

OSBotify · 2026-06-23T21:59:16Z

🚀 Deployed to production by https://github.com/blimpich in version: 9.4.17-3 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	failure ❌

OSBotify · 2026-06-23T23:37:46Z

🚀 Deployed to production by https://github.com/blimpich in version: 9.4.17-3 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	failure ❌

The EMPLOYEES screen back button redirected to a blank Workspaces modal because getDomainPrefix hardcoded both PRIVATE_DOMAIN and WORKSPACES for every private-domain user, even though only one is ever traversed. Gate the private-domain prefix on account validation (mirroring #93399's public-domain fix): unvalidated users keep PRIVATE_DOMAIN, validated users get WORKSPACES, and validated users without joinable workspaces (which auto-skip that screen) get neither. Back now resolves to the screen the user actually came from and the step counter is accurate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

fix: App back button loops between employee step and verify email step

ee86d69

melvin-bot Bot assigned nkdengineer Jun 12, 2026

nkdengineer marked this pull request as ready for review June 12, 2026 09:04

nkdengineer requested review from a team as code owners June 12, 2026 09:04

melvin-bot Bot requested review from ahmedGaber93 and joekaufmanexpensify and removed request for a team and joekaufmanexpensify June 12, 2026 09:05

melvin-bot Bot removed the request for review from a team June 12, 2026 09:05

arekm213 mentioned this pull request Jun 15, 2026

Argent pr qa poc #93592

Closed

nkdengineer added 2 commits June 16, 2026 20:41

Merge branch 'main' into fix/92688

03b3965

block hardware back button when the employee step is the first step

c49ba97

ahmedGaber93 approved these changes Jun 17, 2026

View reviewed changes

melvin-bot Bot requested a review from neil-marcellini June 17, 2026 10:02

jayeshmangwani mentioned this pull request Jun 22, 2026

[Due for payment 2026-07-17] [$250] Onboarding - Back button redirects to a blank modal #93660

Open

7 tasks

Merge branch 'main' into fix/92688

d249f6f

neil-marcellini approved these changes Jun 22, 2026

View reviewed changes

neil-marcellini merged commit b3d324e into Expensify:main Jun 22, 2026
33 of 34 checks passed

OSBotify mentioned this pull request Jun 22, 2026

Deploy Checklist: New Expensify 2026-06-22 #94222

Closed

melvin-bot Bot mentioned this pull request Jun 23, 2026

[Due for payment 2026-06-30] [$250] Onboarding - App back button loops between employee step and verify email step #92688

Closed

7 tasks

dilshodmackbook-sketch mentioned this pull request Jun 30, 2026

fix: onboarding back button redirects to blank modal for private-domain VSB/SMB #95001

Merged

43 tasks

Uh oh!

Conversation

nkdengineer commented Jun 12, 2026

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

melvin-bot Bot commented Jun 12, 2026

Uh oh!

arekm213 commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🧪 Mobile QA — before/after on main vs this PR

Context

Environment & method (please read — repro deviation noted)

iOS App

Before — main (🐞 bug)

After — PR branch (✅ fixed)

Android App

Before — main (🐞 bug)

After — PR branch (✅ fixed)

Result

Uh oh!

ahmedGaber93 commented Jun 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

ahmedGaber93 commented Jun 13, 2026

Uh oh!

nkdengineer commented Jun 15, 2026

Uh oh!

ahmedGaber93 commented Jun 15, 2026

Uh oh!

nkdengineer commented Jun 16, 2026

Uh oh!

neil-marcellini left a comment

Choose a reason for hiding this comment

Uh oh!

neil-marcellini commented Jun 22, 2026

Reviewer Checklist

Screenshots/Videos

Uh oh!

Uh oh!

github-actions Bot commented Jun 22, 2026

Uh oh!

OSBotify commented Jun 22, 2026

Uh oh!

github-actions Bot commented Jun 22, 2026

Uh oh!

OSBotify commented Jun 22, 2026

Uh oh!

MelvinBot commented Jun 22, 2026

Uh oh!

OSBotify commented Jun 23, 2026

Uh oh!

OSBotify commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

arekm213 commented Jun 12, 2026 •

edited

Loading

🧪 Mobile QA — before/after on `main` vs this PR

Before — `main` (🐞 bug)

Before — `main` (🐞 bug)

ahmedGaber93 commented Jun 13, 2026 •

edited

Loading