Problem with "no network" - either minor display issue or severe functionality issue

[Blama]

Hi Isomorphic,

using current 5.1p (v10.1p_2016-04-18) and am just developing email-import functions (as introduction why I got here). To test server error handling I just disabled my ethernet network card (in Win 10), making all my network cards disabled (I also have Wifi and Bluetooth, that are disabled all the time). This resulted in unexpected *client* effects.

My Tomcat server is running locally and can be reached. Loading my application works, but when trying to change data, this happens:

I've never seen those before and am wondering if they are really correct. I can fetch data (but ListGrids say "Can't load data offline" before actually displaying data), but saving does not work. Manually issued UPDATE results in this entry in the Developer Console:

17:33:05.721:TMR3:WARN:Log:Data cannot be saved because you are not online

Now this does not seem perfectly right.
There is definitively an display issue in the lower SC.warn().

Enabling Wifi (but not connecting to a network) does not change the result.
Enabling Ethernet does solve the problem, even before DHCP is done and Internet is available.

Is this expected? I agree that this will happen mostly on development PCs, but if it really needs Internet (it does not, does it?), this would be a serious problem for intranet applications where the browser has no internet access.

This is not an important issue for me, but something strange I noticed.

Best regards
Blama

[Isomorphic]

You haven't made clear whether server contact is still possible in this scenario - is the server on the same machine?

Regardless however, The browser is reporting to SmartGWT that the system is in "offline" mode, and we have no ability to do any kind of more direct check (eg enumerate available network interfaces).

As to the second empty warning dialog, that doesn't look right, but probably comes from your error handling code being surprised by the responses that are generated when offline. Let us know if that appears to come from a framework issue.

[Blama]

Hi Isomorphic,

yes, my Tomcat server is running locally and can be reached. Loading the application works.
It seems that fetches are still issued (and work as the server is running) and updates result in one of the SC.warn() errors or the warning logged in the Development Console.

What do you mean by "by the responses that are generated when offline"? I don't see anything in the RPCManager tab.

Best regards
Blama

[Isomorphic]

This is a very weird situation, but as previously indicated, the browser is actually telling us that it is offline. We don't make that decision and can't influence it. So it looks like you maybe have a bug to report to Chrome.

Go ahead and read the docs for how the Offline subsystem works - the special responses are explained there.

[pablo99]

It's not a Chrome specific issue. It also happens in Internet Explorer. Is there any way to disable this message?

[Isomorphic]

The user above describes a very specific situation involving access to a local server while the Ethernet adapter has been disabled.

If your situation is exactly like this, our answer is the same: we have no control over whether the browser thinks it's offline.

If your situation does not involve a disabled Ethernet adapter, please start a new thread and explain it in detail.

[pablo99]

I have the same setup as the above poster: a local tomcat server running on the same machine that I am using the client. Ethernet and wifi are disabled. But I don't fully understand why the browser being offline would disable calls back and forth from a local server. Standard GWT service calls work as expected in this setup, regardless of the status of the browser. I have tested with IE, Chrome, and Firefox, and get the error message with each.

[Isomorphic]

Please take a look at goOnline(), goOffline() and useNativeOfflineDetection() APIs. These are available in 5.1 as well. You may use goOnline() and goOffline() to manually control online/offline state, which will solve your offline testing issues.