Use browser online/offline state as a hint, assess the actual operation separately, and preserve user work while offering an appropriate retry for the observed failure.
A visitor can read other websites, but your editor displays You are offline and disables Save. Another visitor sees an online indicator even though the service needed to submit the form is unavailable. Both experiences can arise when the interface treats one broad connection hint as proof about a particular operation.
This guide uses a fictional listing editor with a public reading page and a separate save service. It is a proposed review scenario, not a test of a particular application. The aim is to make failure messages and recovery match the evidence the interface actually has.
Treat browser connection state as a hint
MDN’s Navigator.onLine reference explains that browsers and operating systems use different heuristics. A local network connection may count as online without internet access, while a heuristic’s own connectivity check can fail even when useful internet access remains. The property is inherently unreliable; MDN advises against disabling features solely on that basis.
For the listing editor, a network hint can support a cautious message. It should not be the sole reason to discard an edit or prevent a request that might work. Ask the developer what evidence leads to the visible notice and whether the wording claims more than that evidence establishes.
Distinguish the device, the public reading page and the save service in your notes. They are not one health signal. The visitor’s report that other sites work is useful context, but it does not prove that your particular endpoint, credentials or operation are healthy either.
Use connectivity events to reconsider state, not declare success
The MDN offline-event reference documents an event associated with the browser’s connectivity state becoming offline. That is a change signal for the interface to handle. It is not an acknowledgement from the listing service and cannot establish whether an earlier save reached it.
Write the intended reaction to a state change. The editor might preserve the current fields, update a hint and keep a visible way to attempt or retry the appropriate operation. Returning to an online hint should not automatically replace an unsaved document with an older server copy.
Keep event handling and application state separate. A temporary connection transition does not mean that the visitor’s work is invalid. Nor does a later connection transition establish that a queued operation has completed. Let the actual operation’s result control its own success message.
Inspect the request stages separately
The MDN Fetch guide distinguishes request failures from HTTP error responses: a response such as 404 does not by itself reject the fetch promise. Response status and reading or parsing the body are further checks. A fulfilled network request is therefore not automatically a successful application task.
Have the maintainer identify the operation that failed, its timing and the observed result. Was a request attempted? Was there a response? Did the response match the expected operation and contain usable data? Keep diagnostic details in an appropriate support record rather than exposing internal traces to ordinary visitors.
For the listing editor, the public reading page might load while Save needs renewed authentication or the service returns a temporary failure. Calling every such result offline sends the visitor toward the wrong repair. Match the message to what is known and provide a support path when the cause remains uncertain.
| Proposed observation | What it establishes | Interface response to define |
|---|---|---|
| Browser reports offline | A broad connectivity hint changed | Preserve work and explain the limited signal |
| Public page loads, Save fails | Different operations have different outcomes | Investigate the save service separately |
| Service returns an error response | The request received a particular response | Offer the appropriate correction or retry |
| Save acknowledgement is uncertain | Completion is not yet confirmed | Check operation state before resubmitting |
Preserve work before designing a retry
Decide which content should remain visible after a failure. In the fictional editor, the visitor’s title and description should not disappear because a background request was unsuccessful. Make the difference between the current edit and the last confirmed save understandable.
Plan the retry with the operation’s consequences in mind. Re-reading a public resource and resubmitting an action are different tasks. If completion is uncertain, ask the implementation owner how the application checks the existing result or avoids creating a duplicate. Do not simply repeat every request when the network hint changes.
This guide does not redesign offline storage or a synchronization queue. If those features are present, review their own persistence and reconciliation contracts as well. The immediate goal is that a connectivity notice does not conceal whether the current work is saved, pending or still only in the editor.
Build a small failure matrix for the actual service
Use harmless test content in an isolated environment. Ask the developer to simulate a disconnected client, an unavailable service, an error response and an uncertain acknowledgement separately. Record the intended user message, retained work and available next action for each case.
Include a recovery step in the exercise. Restore the relevant connection or service, then confirm how the visitor resumes. Check that the interface does not show Saved merely because a broad online event arrived. The visible confirmation should correspond to the actual operation’s accepted result.
Repeat the supported browser paths deliberately. Record their versions and actual observations rather than treating one simulated network setting as every real mobile-network condition. A reproducible failure matrix is more useful than a screenshot containing only the word offline.
Keep the message precise and actionable
Choose wording that separates the known result from a suspected cause. An unable-to-confirm-save notice can be more accurate than a confident claim that the visitor has no internet. Provide a retry or correction path suited to the operation and a support route if the state remains unclear.
Use An installed website keeps the old version: diagnose its service worker, Browser storage full or missing: diagnose quota, eviction and unsaved website data and Fix broken website buttons and blank screens with Console and Network evidence for adjacent resilience work. The useful outcome here is a website that treats connection state as evidence with limits, preserves the visitor’s effort and confirms service success through the operation itself.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN — Navigator onLineChecked Browser/OS connectivity heuristics are unreliable indicators of internet or specific-service reachability.
Limits: Use as a hint, not sole evidence for disabling a feature. - MDN — Window offline eventChecked The event reports a change in the browser network-state signal.
Limits: Does not report the health or success of a particular application operation. - MDN — Using the Fetch APIChecked Network errors, HTTP response status and parsing/body outcomes are separate stages.
Limits: A response status alone does not establish business success or persisted work.