Context
We have an OmniScript that calls DataRaptor/Integration Procedure remote actions to pull data. When a device loses network mid-session, the remote action call fails and OmniScript throws a hard error instead of degrading gracefully. A red error banner names the failing element, shows true underneath, and the "Continue" button doesn't actually recover the flow.
Fix implemented
Before triggering the DataRaptor/IP remote action, we register listeners for the browser's connectivity events:
js
window.addEventListener("online", handleOnline);
window.addEventListener("offline", handleOffline);
On offline → we set a flag and intercept the remote action call, showing a friendly "you're offline" message instead of letting the call fail and throw the error block.On online → we clear the flag and let the remote action proceed normally.
We also check navigator.onLine at call-time as a secondary guard.
This works correctly for every user we've tested, across web (all major browsers) and Mobile Publisher — the offline event fires reliably, our handler runs, and the graceful message shows up instead of the hard error.
The problem
For exactly one user, on Chrome, neither the offline event nor the online event appears to fire at all when the device's actual connectivity changes. Because our handler never runs, the flag never gets set, the remote action call goes through as if the device were offline, and the original OmniScript error surfaces.
Affected environment
- OS: Ubuntu 24.04.2 LTS
- Device: Lenovo laptop
- Chrome: Version 151.0.7922.137 (Official Build) (x86_64)
Question for the community
Has anyone seen window.addEventListener("online"/"offline") fail to fire on Chrome for Linux (Ubuntu 24.04) on a specific machine, in an OmniScript/LWC context, while working fine on the same OS/browser combo for other users?
Thanks!
#Salesforce #Omnistudio #DataRaptor #Chrome Browser
Hi Rakesh - the root issue is that the window online/offline events (and navigator.onLine) are inherently unreliable, and Linux Chrome is the worst case. Chromium marks the browser 'online' whenever there is any network interface with an IP - even a virtual or IPv6 adapter with no real internet - and it often never fires the offline event on Linux. So on that one Ubuntu user's machine the events genuinely will not fire; it is a documented Chromium limitation, not your code.
So do not gate your OmniScript logic on those events. Two robust patterns instead:
1. Handle the failure at the call, not before it. Wrap the DataRaptor IP remote action so that when it fails (network error or timeout) you catch it and show your friendly 'you are offline' message plus a real retry - rather than trying to predict offline up front. In OmniScript, use the element's error handling / a Set Errors plus conditional navigation so the hard error banner never shows.
2. If you want a proactive signal, run a lightweight heartbeat - a periodic fetch to a tiny known endpoint with a short timeout - and treat a failed or timed-out fetch as offline. That actually tests reachability, which the browser events do not.
navigator.onLine is fine as a hint (if it says false, you are definitely offline), but never as the source of truth. Catching the actual remote-action failure is what fixes the ungraceful error for everyone, including that Ubuntu user.
If this helps, please mark it as the Best Answer so it helps the next person - thanks :)
