Skip to content

[Due for payment 2026-10-27] Web- Browser back button doesn't dismiss "You appear to be offline" alert #104154

Closed

Description

@applause-bot

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.


Version Number: v9.5.10-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #103554
Email or phone of affected tester (no customers): gd868gd+1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Desktop / Windows 11
App Component: Other

Action Performed:

Preconditions:

  • The account has a workspace.
  • There are a couple of unreported expenses.
  • There are a couple of expenses in a report.
  1. Open the Expensify WebApp and log in with the account from the Precondition
  2. Go to Account / Troubleshooting and switch the "Force offline" toggle on
  3. Go to Search / Expenses and select several different expenses
  4. Click on "Export" and select any option ("Basic export", for example)
  5. When the "You appear to be offline" modal appears, click the browser back button and observe

Expected Result:

The "You appear to be offline" modal should be dismissed.

Actual Result:

The "You appear to be offline" modal is not dismissed.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

_To b

Bug7287536_1792091369696.Expensify_PR103554_Back_Web.mp4

e added by Applause Leads_

View all open jobs on GitHub

Applause Internal Information
Exported by: Chandana Kiran
Bug ID: 7287536

Issue OwnerCurrent Issue Owner: @mallenexpensify

Activity

  1. added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Oct 15, 2026
  2. applause-bot commented on Oct 15, 2026

    @applause-bot
    Author

    While Applause doesn't embed attachments for this bug, here are the links for quick view:
    https://platform.applause.com/services/links/v1/external/9b4c88ebdd604ea4de683438140fb243b5de4b2aeba0c6cb985585ee43690132

  3. melvin-bot commented on Oct 15, 2026

    @melvin-bot

    @roryabraham recently merged #103554, but they are OOO right now, so I'll auto-assign someone else.

  4. melvin-bot commented on Oct 15, 2026

    @melvin-bot

    Triggered auto assignment to @carlosmiceli (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

  5. github-actions commented on Oct 15, 2026

    @github-actions
    Contributor

    👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

    1. Identify the pull request that introduced this issue and revert it.
    2. Find someone who can quickly fix the issue.
    3. Fix the issue yourself.
  6. melvin-bot commented on Oct 15, 2026

    @melvin-bot

    @roryabraham @ZhenjaHorbach you have been assigned to this deploy blocker because you reviewed the offending PR: #103554

  7. melvin-bot commented on Oct 15, 2026

    @melvin-bot

    💬 A slack conversation has been started in #expensify-open-source

  8. MelvinBot commented on Oct 15, 2026

    @MelvinBot
    Contributor

    Deploy Blocker Analysis

    Causing PR: Use useDecisionModal for Search bulk actions and SelectionToolbar alerts (high confidence). It is a real regression: production dismisses the modal on browser Back.

    Recommendation: Revert. The revert applies cleanly to staging (a3d62cc) and main (7e9ad84). The PR is a refactor, so reverting costs little. There is no verified small roll-forward fix yet.

    Root cause: The PR replaced the inline <DecisionModal> in the Search screen with the global useDecisionModal modal, which renders at the app root. Before, browser Back navigated away and the modal went with the screen. Now the modal lives outside the screen, so only its history back-guard can close it, and that guard does not fire in this flow.

    Investigation details

    Why this PR

    Production

    Staging

    Why the guard doesn't fire (unconfirmed hypothesis): In @react-navigation/native 7.4.1, browser Back sends goBack() to the innermost active navigator. If the Search stack or tab history can go back, it handles the action, so the root-level guard entry is never removed. I did not reproduce this in a running app.

    Why not a quick fix

    • Setting shouldHandleNavigationBack: false makes it worse: Back navigates, but the root modal stays on top.
    • Closing the modal from a navigation listener risks an extra browser back when the guard cleans up.
    • Before re-landing, prove the guard closes on browser Back in Search and SelectionToolbar, and add a test for it.

    Severity: Low. It affects web only, offline only, after browser Back, and "Got it" still dismisses it. Demoting is defensible if the team wants to keep the refactor. Given the clean revert and the Android stuck-alert risk, reverting is the safer choice.


    Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.


    view run

  9. 15 remaining items

  10. ZhenjaHorbach commented on Oct 23, 2026

    @ZhenjaHorbach
    Contributor

    I suppose it's a separate issue and not a regression
    Since all modals were broken

  11. added
    Awaiting PaymentAuto-added when associated PR is deployed to production
    and removed on Oct 26, 2026
  12. melvin-bot commented on Oct 26, 2026

    @melvin-bot

    Triggered auto assignment to @mallenexpensify (Awaiting Payment)

  13. melvin-bot commented on Oct 26, 2026

    @melvin-bot

    Payment Summary

    Resolving PRs:

    BugZero Checklist (@mallenexpensify)

    • I have confirmed assignees, roles, and Upwork contracts look correct
    • I have paid out Upwork contracts / manual NewDot requests
    • [BugZero Assignee] I have created a GH issue for creating/updating the regression test once above steps have been agreed upon
  14. melvin-bot commented on Oct 29, 2026

    @melvin-bot

    @mallenexpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

  15. mallenexpensify commented on Oct 30, 2026

    @mallenexpensify
    Contributor

    Payment Summary

    Contributor+: @ZhenjaHorbach due $175 via NewDot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Awaiting PaymentAuto-added when associated PR is deployed to productionBugSomething is broken. Auto assigns a BugZero manager.DailyKSv2Engineering

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions