Skip to content

fix: false offline screen from unreliable navigator.onLine - #1877

Merged
Gauravjeetsingh merged 2 commits into
KhalisFoundation:devfrom
divyanshugarg36:fix-false-offline-screen
Aug 7, 2026
Merged

fix: false offline screen from unreliable navigator.onLine#1877
Gauravjeetsingh merged 2 commits into
KhalisFoundation:devfrom
divyanshugarg36:fix-false-offline-screen

Conversation

@divyanshugarg36

Copy link
Copy Markdown
Contributor

Some users (seen in Chrome) get navigator.onLine === false while actually connected, which permanently pinned the app on the offline screen — the online event only fires on a transition, so a false initial value never self-corrected.

  • Start optimistic (store online: true) instead of trusting navigator.onLine.
  • On mount, only if navigator.onLine reports offline, confirm with a real same-origin request (verify-online util) and set online from the result.
  • Verify the offline event the same way before showing the offline screen.

Some users (seen in Chrome) get navigator.onLine === false while actually
connected, which permanently pinned the app on the offline screen — the online
event only fires on a transition, so a false initial value never self-corrected.

- Start optimistic (store online: true) instead of trusting navigator.onLine.
- On mount, only if navigator.onLine reports offline, confirm with a real
  same-origin request (verify-online util) and set online from the result.
- Verify the offline event the same way before showing the offline screen.
Comment thread src/js/util/verify-online.ts Outdated
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), timeoutMs);
try {
await fetch(`/favicon.ico?_=${Date.now()}`, {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might give us false positive. How about using the health endpoint in the app, or use the one provided in API?

And returning value based on an actual response, instead of just a request completion.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I updated it to ping banidb/health endpoint

Address review: the favicon HEAD only proved *a* request completed (a captive
portal, a same-origin SPA fallback, or a 4xx/5xx all returned true). Probe the
banidb API /health endpoint the app actually depends on and return response.ok,
so a real 2xx from the backend is required to consider the app online.
@Gauravjeetsingh
Gauravjeetsingh merged commit 1e6aa12 into KhalisFoundation:dev Aug 7, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants