Safari Request Behavior

[Bob Lacatena]

I work on a web app which is a multi-user simulation used in training. As such, we have a wide variety of users, but the simulation is very interactive, with the "players" making decisions that are recorded on the backend, update the business model, and then reflect changes in everyone's user interface (browser).

A lot of work has gone into keeping things in synch among 100+ simultaneous users. In particular, many users have bad Internet connections (since the pandemic, many use horribly configured home networks) so extra effort is put into detecting message failures, retrying, or alerting users that their communication with the server is inadequate (so they don't think things are working when they aren't).

In particular, we now have more and more Safari users, and Safari does not handle connections, connection pooling, and error reporting the way that Chrome or Firefox (or Edge) do.

Safari will occasionally show the following error in the browser console:

[Error] Failed to load resource: The network connection was lost. 

With respect to GWT requests, Safari often doesn’t deliver a normal onreadystatechange with a status code; instead it fires the XHR onerror (or onabort/ontimeout) path with status === 0. RequestBuilder doesn't detect this,, so our code is not detecting situations where a request fails in this way.

[We detect this in Chrome because it will normally throw a StatusCodeException with a status code of zero.]

[According to ChatGPT...] This happens often with Safari because Safari/WebKit is pretty aggressive about reusing TCP connections, and so can randomly throw this at any time it tries to reuse a connection that has gone stale (it apparently doesn't detect the problem and try a different connection itself).

We have seen this behavior happen a lot, to the extent that we basically can't allow users to use Safari with our web simulations.

I have some suggestions from ChatGPT (which I really don't trust much) that we can take action on to try to detect this edge case (no idea if it will really work), but it would be far simpler if this was built into GWT and the RequestBuilder (and possibly translated into a StatusCodeException or some other special construct that is browser-agnostic).

NOTE: There is no urgency to this "request". Our current off ramp is to just tell clients that users may not use Safari. But I'd love it if you solved the problem for us (someday).

[Craig Mitchell]

The For my GWT RPC calls, I create a RequestBuilder with a timeout, so the caller knows if the request never came back, and can deal with the consequences.  Ie:

public static RpcRequestBuilder createRpcRequestBuilder(int timeoutInMs) {
  return new RpcRequestBuilder() {
  @Override
    protected RequestBuilder doCreate(String serviceEntryPoint) {
      RequestBuilder builder = new RequestBuilder(RequestBuilder.POST, serviceEntryPoint);
      builder.setTimeoutMillis(timeoutInMs);
      return builder;
    }
  };
}