[ON HOLD] Fix false offline state on web (Safari)#84277
[ON HOLD] Fix false offline state on web (Safari)#84277adhorodyski wants to merge 1 commit intoExpensify:mainfrom
Conversation
Codecov Report❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.
|
|
@m-natarajan are you able to reproduce this please with this PRs fix? Unfortunately I wasn't able to reproduce the OG bug myself. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2a2706407b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (state.isInternetReachable === false && typeof navigator !== 'undefined' && navigator.onLine) { | ||
| Log.info('[NetworkConnection] NetInfo says unreachable but navigator.onLine is true — skipping offline to avoid false positive'); | ||
| return; |
There was a problem hiding this comment.
Keep server-outage offline updates despite navigator guard
This early return bypasses the existing setOfflineStatus(state.isInternetReachable === false || !isServerUp, ...) path whenever navigator.onLine is true, so a backend outage (where reachabilityTest sets isServerUp = false but the browser still reports online) will no longer mark the app offline. In that scenario users stay in an online state while API calls fail, which is a regression introduced by this guard.
Useful? React with 👍 / 👎.
@adhorodyski Is this PR ready for retest? or Do we have to wait till the status change to Merged? |
|
@adhorodyski @m-natarajan I think we should create an ad hoc build for this PR and ask QA to test it. |
|
Ready for testing, you need an adhoc right? Cc @mountiny |
|
No product review needed |
|
🚧 @mountiny has triggered a test Expensify/App build. You can view the workflow run here. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
@m-natarajan Could you test the issue with the ad hoc build here? |
|
Chrome / Safari - v9.3.31-4 PR:84277 09.59.57.mp4 |
|
@mjasikowski should we hold off here and retest with #84760 soon? |
|
@adhorodyski I assume if we push #84760, then this will be redundant, so let's hold off here for now |
|
Lets add this PR on HOLD then to make it clear from the title |
Explanation of Change
Before setting
offlineStatusto true based on NetInfo's Ping failure, we checknavigator.onLine. If the browser reports the network adapter is connected (navigator.onLine === true) but NetInfo's Ping timed out (isInternetReachable === false), we skip setting offline — it's a false positive from Ping contention (e.g., during a large upload).The guard only activates on web (where
navigatorexists). On native,navigatoris undefined so the guard never fires. Real disconnects still work because the browser fires anofflineevent settingnavigator.onLine = false.Only one file was changed:
src/libs/NetworkConnection.ts— added anavigator.onLineguard in the NetInfo event listener to prevent false offline state in Safari during upload contention.Fixed Issues
$ #83780
PROPOSAL:
Tests
Reproduce the false-positive offline scenario:
[NetworkConnection]log messages)NetInfo says unreachable but navigator.onLine is true — skipping offline to avoid false positiveand no offline bannerVerify real offline still works:
navigator.onLinewill also befalse)Safari-specific testing (if available):
Offline tests
N/A
QA Steps
Same as tests
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari