Bug 32327 – ononline, onoffline and navigator.onLine don't work if Parallels or VMWare is installed

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore JavaScript

[Ryan Grimm]

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).

[Alexey Proskuryakov]

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.

[Ryan Grimm]

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.

[Alexey Proskuryakov]

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.

[Ryan Grimm]

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).

[Alexey Proskuryakov]

*** Bug 52491 has been marked as a duplicate of this bug. ***

[Thomas Steiner]

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)

[Chris Dumez]

Created attachment 330048 [details]
Patch

[Chris Dumez]

Created attachment 330049 [details]
Patch

[Alexey Proskuryakov]

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.

[Chris Dumez]

(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

[WebKit Commit Bot]

Comment on attachment 330049 [details]
Patch

Clearing flags on attachment: 330049

Committed r226238: <https://trac.webkit.org/changeset/226238>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/36183968>