Bug 32327

Summary: ononline, onoffline and navigator.onLine don't work if Parallels or VMWare is installed
Product: WebKit Reporter: Ryan Grimm <grimm>
Component: WebCore JavaScriptAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, beidson, cdumez, commit-queue, darin, ggaren, mroy, tomac, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Mac (Intel)   
OS: OS X 10.6   
URL: https://bug336359.bugzilla.mozilla.org/attachment.cgi?id=220609
See Also: https://bugs.webkit.org/show_bug.cgi?id=181079
Attachments:
Description Flags
Patch
none
Patch none

Description Ryan Grimm 2009-12-09 09:51:23 PST
When going offline or coming back online my understanding is that according to the HTML 5 spec the ononline/onoffline events should fire accordingly and the navigator.onLine property should report the current online state when accessed.  In the latest nightly builds as well as Safari 4, these events don't fire and navigator.onLine always appears to return true.  To reproduce the problem, load the provided URL and disconnect your network connection.  The top box should turn red and report an offline state.  To see an example of the behavior I was expecting, try the same procedure using FireFox (3.5).
Comment 1 Alexey Proskuryakov 2009-12-10 14:09:20 PST
Do you happen to have Parallels or VMWare installed? These set up fake network adapters that are always connected, so the machine is always "online" in a way.
Comment 2 Ryan Grimm 2009-12-10 23:20:12 PST
Good call, I actually do have VMWare installed.  I took a look at the source of NetworkStateNotifierMac.cpp and now that you mention this it makes total sense.  However, I am wondering why it's not using something like SCNetworkReachabilitySetCallback() instead of counting interfaces.  I'm not suggesting that it should, I'm just genuinely curious.
Comment 3 Alexey Proskuryakov 2009-12-11 00:16:56 PST
What target should we use with SCNetworkReachabilitySetCallback? What if the page in question is actually opened from a server running in VMWare?

Indeed, there are many cases where online/offline and navigator.onLine events are broken by design. For example, if I'm connected to VPN, and open a Web application from internal network, should an offline event be dispatched once I disconnect from VPN? Or what if a page that's open from intranet fetches its data from an external source with XMLHttpRequest, and a link to that external source gets dropped?

Exposing something like SCNetworkReachability to Web applications could make sense in my opinion, but a binary online/offline flag just doesn't describe the reality well.
Comment 4 Ryan Grimm 2009-12-11 11:47:13 PST
You are quite correct on all points.  Even trying to ignore the interfaces that VMWare adds would likely leave a browser running inside a VM in an eternally "offline" state.  However, somehow FireFox does not seem to have this exact issue with VMWare being installed.

I did a little bit of digging around and it looks like setting the target address to 0.0.0.0 is a good indication that an interface is available.  I haven't played around with this yet so I don't know what it would trade off but figured I'd throw it out there for consideration (if it hasn't been already).
Comment 5 Alexey Proskuryakov 2011-01-14 22:54:08 PST
*** Bug 52491 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Steiner 2017-12-21 00:47:03 PST
I do have Parallels installed, but am running Safari outside of the virtual machine. Still a simple online/offline test fails (go to https://codepen.io/anon/pen/ZvOwGa, turn WiFi on and off), whereas it works as intended on other browsers. This messes with Service Workers, as the browser always reports to be offline when actually it's not.

Safari Technology Preview, Release 46 (Safari 11.1, WebKit 12605.1.18.2)
Comment 7 Chris Dumez 2017-12-21 12:14:19 PST
Created attachment 330048 [details]
Patch
Comment 8 Chris Dumez 2017-12-21 12:14:51 PST
Created attachment 330049 [details]
Patch
Comment 9 Alexey Proskuryakov 2017-12-21 12:31:24 PST
Comment on attachment 330049 [details]
Patch

I guess having these hardcoded checks is better that having the problem, r=me. But I still hope that we can get a more sensible API exposed one day.
Comment 10 Chris Dumez 2017-12-21 12:39:16 PST
(In reply to Alexey Proskuryakov from comment #9)
> Comment on attachment 330049 [details]
> Patch
> 
> I guess having these hardcoded checks is better that having the problem,
> r=me. But I still hope that we can get a more sensible API exposed one day.

Agreed
Comment 11 WebKit Commit Bot 2017-12-21 13:00:53 PST
Comment on attachment 330049 [details]
Patch

Clearing flags on attachment: 330049

Committed r226238: <https://trac.webkit.org/changeset/226238>
Comment 12 WebKit Commit Bot 2017-12-21 13:00:55 PST
All reviewed patches have been landed.  Closing bug.
Comment 13 Radar WebKit Bug Importer 2017-12-21 13:01:33 PST
<rdar://problem/36183968>