Application.internetReachability

Does this work at all with WebGL builds? Because it doesn't seem to work at all. Even if I unplug my modem the result still says "Reachable Via Local Area Network".

If it doesn't work, is there another way to check for an internet connection? Preferably without something from the asset store, because I've tried a few things from there and none of them have worked.

And sometimes if I try to make a web request when an internet connection is not available, I receive an exception and my game completely stops. However, if I create a build that has Enable Exceptions set to "Full with Stacktrace" then I don't receive any exceptions, only a variety of "Cross-Origin Request Blocked" warnings.

Using Unity 2018.2.6

 

The case is 1079794

 

I've never filed a bug report before. Do these get read in a timely fashion, or is it one of those "the validity of your issue is based on how much you pay us" types of things?

 

I'm sure it's possible to implement such a thing in javascript, but I don't know how. It would be nice if basic functionality didn't arbitrarily stop working on certain platforms.

I've tried creating my own internet connection check using a UnityWebRequest to download a text file from my own personal server, but after the file has been downloaded it's stored in the browsers cache and any future requests will simply use the cached version and not download a new one. I've gotten around this by adding + "?rand=" and a random number to the web request url, but now this is just getting convoluted and annoying.

Edit: setting the text file's Cache-Control metadata to "private, no-store, max-age=0" seems to fix the cache issue, which means I don't have to do weird things with random numbers (at least with FireFox), but I don't know enough about networking/web requests to determine if this is a viable, reliable way to check for an internet connection when I might potentially have thousands of users.

 

I've found a few different features/functions that work perfectly fine on other platforms but silently fail or don't work at all when used in a WebGL build. Most of them are minor things (like Envrionment.Newline), but the internet reachability was the only one that really made my day difficult.

The bug report handlers said they were able to replicate my issue and will be sending it to the development team, so hopefully this topic won't be needed anymore.

 

I actually disagree with this whole thread (and Unity QA). InternetReachability is working as intended imo. Remember despite its name, this function does not actually test if you're connected to the internet. It's intended for mobile platforms to determine if a user is on wifi or cellular (e.g. we ask users only on cellular are they sure they want to download 50 MB worth of asset bundles). It can also be used on native platforms to quickly test if there's even a possibility of a networked connection (i.e. is the user even connected via ethernet or wifi?).

In other words, this function is basically nonsensical for WebGL (they have no way of knowing whether you're connected to a router/modem, so this call will always return NetworkReachability.ReachableViaLocalAreaNetwork). The best way to actually test for internet connection is make a test call to your server and have it return some "success response" (we do this with our servers, we more or less have a "ping endpoint"). The trick though is not to do it with a file (as you tried) but with a server call (php, etc.) so browsers can't cache. We actually use this "trick" on all platforms not just WebGL since InternetReachability is not reliable.

 

@Marco-Trivellato what's the status of this. I checked it this week (for the last version of Unity 2018) and it's still not working as expected on WebGL. Is it fixed with 2019?

I disagree with kognito... if the wifi is turned off on my device and I'm not connected with cable, then it seems pretty obvious to me that internetReachability should return NetworkReachability.NotReachable, even if it is from WebGL. We've been using alternative solutions (e.g. pinging a stable website and waiting for a response) but have run into CORS issues. All this is solvable, but it's also a big waste of time for something that should be a one-liner.