Summary: | ononline, onoffline and navigator.onLine don't work if Parallels or VMWare is installed | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ryan Grimm <grimm> | ||||||
Component: | WebCore JavaScript | Assignee: | 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
Ryan Grimm
2009-12-09 09:51:23 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. 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. 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. 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). *** Bug 52491 has been marked as a duplicate of this bug. *** 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) Created attachment 330048 [details]
Patch
Created attachment 330049 [details]
Patch
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.
(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 on attachment 330049 [details] Patch Clearing flags on attachment: 330049 Committed r226238: <https://trac.webkit.org/changeset/226238> All reviewed patches have been landed. Closing bug. |