navigator.onLine returns false even though there is internet connectivity
Reported by
con...@superhuman.com,
Jan 3 2017
|
|||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: I am not sure how to reproduce this reliably. It happens rarely for us in background extension pages with multiple iframes where we're using WebSockets for communication with Firebase. It may be triggered by resuming a Mac laptop from sleep, but again the failure rate is relatively low. 1. navigator.onLine returns false 2. fetch(...) works, indicating that the internet is in fact connected. What is the expected behavior? navigator.onLine should always be true when there is connectivity (it is also allowed be true when there is not) What went wrong? Not sure, we've seen this in production a handful of times mostly because it interacts badly with Firebase (which assumes that navigator.onLine errs only by being too truthy). Did this work before? N/A Does this work in other browsers? N/A Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.12.2 Flash Version: Shockwave Flash 24.0 r0 I'm very happy to do some more digging,
,
Jan 5 2017
Thanks for the report. Are you able to check whether or not this happens on other platforms?
,
Jan 5 2017
,
Jan 5 2017
Thanks for the report. This sounds vaguely familiar to me. I'm curious if it's just the case that the onLine status change hasn't propagated down to the renderer before you made the fetch request or if the onLine value never updates. Do you have any way of figuring that out?
,
Jan 5 2017
,
Jan 5 2017
I've heard reports of navigator.onLine not working in background extension pages before, back in 2012/2013. Can you provide a pointer to your extension?
,
Jan 5 2017
,
Jan 5 2017
,
Jan 5 2017
Hey all! This happens extremely rarely while testing, so I'll try and catch it next time and debug in more detail. A few things I am sure of: @tyoshino: most of our users are on mac, so we haven't seen this on Windows/Linux. It's possible it appears on windows but we probably don't have enough operational experience to see it if it does. @jkarlin: navigator.onLine was persistently false (we were able to open the chrome inspector and play around for many minutes). I assume, but we didn't try, that turning the WiFi on and off would have fixed the problem. @pauljensen: The extension in this case was our development extension: https://chrome.google.com/webstore/detail/superhuman-development/njjdbpnpghgincmdglpkkdkgpcjbplpo but we've seen logging that is indicative of the same problem from our production extension: https://chrome.google.com/webstore/detail/superhuman/dcgcnpooblobhncpnddnhoendgbnglpn. I can add your email address to the early beta if you'd like to try it out. The structure of the background page is: <html> <iframe> <iframe> </html> in this case both the top-level frame, and each iframe was stuck in the same state.
,
Jan 13 2017
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 18 2017
,
Jan 18 2017
Was it only the background page and its frames returning false? If you opened a new page and checked it out in dev-tools was it also false?
,
Jan 18 2017
As I recall it was only the background page (though we've fixed the problem on our end now, so haven't tried to reproduce it yet). Foreground (non-extension) tabs that were open at the same time were online correctly.
,
Jan 18 2017
Sounds like a Blink plumbing issue, adjusting component accordingly.
,
Jan 19 2017
If this is happening only in background pages then it seem likely that there's an extension-specific race condition here. Moving to Extensions component. Unless, tyoshino@ you think this should be tracked as a generic Blink>Network APIs issue? Eg. perhaps this is likely to reproduce inside a service worker as well?
,
Jan 19 2017
Blink>Network component can be used for navigator.onLine, yes, though we're not familiar with it yet. No idea about SW case. 55.0.2883.95 which the reporter is using is before Mojofication (r426003). So, it's not related. Hmm...
,
Feb 23 2017
This issue may be fixed by https://codereview.chromium.org/2704083002. Looking at the code deleted in Page.cpp is the following comment: // FIXME: There is currently no way to dispatch events to out-of-process frames.
,
Jul 6 2017
We are also seeing this on a Cordova app on Android (Huawei Honor 8, FRD-L09, Chrome/59.0.3071.125): navigator.onLine is stuck at false after a while even though network access works fine. Typically it takes about a day until it happens, with multiple transitions between networks. The main problem is that it breaks firebase, which will not update while onLine=false. When changing the network again (i.e. cycling between WiFi and cellular network) it usually gets unstuck. For the record, here is the network info while on wifi when the bug was observed: HWFRD:/ $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
,
Jul 17 2017
Comment 19 & 20: Please collect net-internals log covering when onLine goes from true to false but does not correctly flip back to true, and file new bugs. http://dev.chromium.org/for-testers/providing-network-details
,
Sep 5 2017
Hi, We have seen this on a few macOS pc's in a web app as well. All of the incidents happened when the computer went to sleep but not sure how to reproduce yet. Also it reported consistently online false until we close the browser. Unfortunately we do not have the network-log neither. Chrome ver: 60.0.3112.113 (Official Build) (64-bit) macOS 10.12.6 Cheers,
,
Sep 7 2017
I just walked through the code from Blink to //net. It all looks fine and there's nothing platform-specific until we get to //net/base/network_change_notifier_mac.cc. The notification to Blink is triggered by NotifyObserversOfMaxBandwidthChange(), so if that is called when the network comes online everything should work fine. Looking at the file, nothing jumps out, although it could miss ABA changes. Changing components as it does not appear to be a Blink issue.
,
Sep 7 2017
@ricea: Blink plumbing was suspected because this failure only shows up for background pages, while at the same time foreground pages were displaying the correct navigator.onLine value. See comment #13. I've been hearing similar reports of background pages not showing the correct navigator.onLine values since 2012.
,
Sep 7 2017
There might be a race at renderer startup. BrowserOnlineStateObserver::Observe() is triggered by NOTIFICATION_RENDERER_PROCESS_CREATED and then sends a mojo message to the renderer. If any Javascript managed to run before that message arrived it would see navigator.onLine as true.
,
Sep 7 2017
Hmm this bug is generally reported as background pages seeing navigator.onLine as false incorrectly, not true.
,
Sep 7 2017
The Blink plumbing is extremely straightforward by Blink standards--I just followed the trail from https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/NavigatorOnLine.h. There's an override mechanism that is used by tests and DevTools, but I assume people would know if they'd done that.
,
Sep 14 2017
It doesn't look like we're waiting on the OP for anything, so removing the Needs-Feedback label. Feel free to re-add (with explicit comments about what's being waited for) if I'm wrong.
,
Sep 14 2017
I'd love to track down and fix this issue but without a reproduction case (perhaps a set of steps that can be repeated until failure) we're only left with manual code inspection, which has not shed light on this issue. For now I'm closing as cannot-reproduce but feel free to reopen or file a new bug if you have a test case that demonstrates the failure.
,
May 30 2018
I don't have a repro case, but Google Keep web front end gets reports about this routinely (not often, but consistently around one/month for years). Not a background page or an extension, just a regular browser tab. It always goes like this 1) The Google Keep UI tells the user they are offline. Then if I'm able to contact the user: 2) I ask the user to check dev tools Js console for navigator.onLine. It's false. 3) Their browser is otherwise working fine, clearly online 4) Refreshing the tab doesn't help In the future, I'll also ask the user to collect net-internals log with http://dev.chromium.org/for-testers/providing-network-details and report back here. Our current work around is to do some manual network checking (sample requests) when navigator.onLine is false.
,
May 30 2018
@joguntebi: A net-internals log would be great but it may not be terribly useful if it starts after the problem is encountered. An interesting data point would be to ask users experiencing this issue to try going to another tab and seeing what navigator.onLine returns in that tab's JS console.
,
May 30 2018
It would also be useful to know the platform (Android, Linux etc.) on which you are receiving the bug reports on. Some parts of the API are unique to the platform.
,
May 31 2018
I've also seen reports caused by this bug, and also cannot reproduce the issue myself. All reports were on macOS/OS X (ranging from 10.10 to 10.13), and using the Chrome browser (in a tab). Chrome versions within the 66 range. I wonder if this has anything to do with Chrome's auto-update. The timing seems a little suspicious, and the issue seems to disappear after applying the update. It reminds me a little bit of https://bugs.chromium.org/p/chromium/issues/detail?id=777863...
,
Jun 12 2018
I just encountered what appears to be this issue. I noticed Slack failed to load correctly. In the console, it was logging "Jun-12 08:50:36.316 Internet connection still offline after 82 attempts (browser says it is still offline)" over and over again. I also noticed that when I visited a domain with no A/AAAA record, I got an ERR_INTERNET_DISCONNECTED message instead of an ERR_NAME_NOT_RESOLVED message. I then checked the value of navigator.onLine. It was returning false (both in the Slack tab and in new tabs). I definitely had internet access because I was using Google Search, I was making DNS queries in Terminal.app, and Firefox reported true for navigator.onLine. Based on comment #33, I checked the update status before restarting Chrome. It reported that Chrome was up to date. I quit Chrome and opened it again and the bug was gone. Chrome version (chrome://version is attached): Google Chrome is up to date Version 67.0.3396.79 (Official Build) (64-bit) macOS version: 10.13.4 (17E202) I know Docker for Mac messes with some network settings such as the firewall, so it might be relevant that I was running that during the incident (although I didn't need to restart Docker for Mac to fix the issue).
,
Jun 13 2018
#34 I think you may have found something. https://cs.chromium.org/chromium/src/net/base/network_change_notifier_mac.cc only checks the reachability of the address 0.0.0.0. It's possible to have IPv6-only connectivity and be able to do Google searches while 0.0.0.0 is unreachable. However, I can't reproduce this. If I turn off IPv4 in the Network panel of System Preferences, "ping 0.0.0.0" gives "No route to host" and "nc -v -u 0.0.0.0 52" gives "Network is unreachable", but navigator.onLine still reports true. Maybe there's some other necessary condition I'm missing.
,
Aug 7
This just happened to be today, with my ServiceBuilder app in Chrome on a Macbook. Turning the wireless off, then back on, fixed the problem.
,
Sep 4
This just happened to me this morning, right after logging in (I think Chrome started up before my Wifi had finished connecting). The following page, as well as all instances of my web app, reported navigator.onLine as false even as I was able to browse the web fine (google searches, hacker news, unsplash, etc.). http://html5-demos.appspot.com/static/navigator.onLine.html I'm running the latest Chrome (Version 68.0.3440.106) on a Macbook Pro w/ High Sierra. Like #34, turning my Wifi off and on again resolved the issue. Thanks again for looking into this!
,
Dec 19
Came across this issue today on Chrome 71.0.3578.98 (latest). As mentioned, `navigator.onLine` was incorrectly set to `false`. What is interesting though, is that something else that was relying on the `online` and `offline` events appeared to work just fine. Naturally I have no idea how navigator.onLine is being set in the browser, but perhaps the event is not getting through, or is not being used? Just a thought.
,
Dec 19
,
Dec 19
|
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by ajha@chromium.org
, Jan 4 2017