Table of Contents maxLevel 2
...
This can be customised by adding the following code snippet to your answerSpace.
https://gist.github.com/jokeyrhyme/9f93805fe86c9f37f7e3
There are 2 snippets here, the ajax-spy.js will just help you figure out if the timeout is not being set properly.
...
error 0 is the last attempt by the client to provide the user with a graceful failure. Because error 0 is a client side error and only occurs at a point when the client has not received any error / success codes from the server there is very limited information available to display.
Who creates the text “error 0”?
How to reduce the likelihood of error 0?
Limit the amount of time required to perform a form action (eg. submitting the form).
Limit the time that the client is waiting while connected to the network thus limiting the window in which something could go wrong.
If your process contains multiple transactions / posts you should ensure sufficient error trapping at each point of transaction and notify the client prior to the timeout period.
Form design and best practices
Preprocess information as much as possible then send one single submission that is as small as reasonably possible.
When preprocessing data, limit the number of variables and arrays in play. Practice smart coding, re-use variables where possible as creating multiple copies of large items such as $data could cause server side memory limits to be reached.
Add “try / catch” statements, or at the very least “if” statements, to your code. This allows your code to fail gracefully as you will be displaying an error to the user when something isn’t working as expected. This also allows you to easily see where in the process things may have failed.
If the user is working in areas with low connectivity, suggest a workflow change. Perhaps the user should save forms to the pending queue on their device and submit when back in the office rather than submitting in the field.
Our goal is to ensure that the user has a sleek and fast mobile experience. We should ensure that the workflow that we put in place enables this level of experience.
Post-submission flow
1. is the HTTP status 200? is there a response body? do the UUID and submission times match? if the body is JSON, is the errors section missing or empty? if ALL of this is YES, then we consider the submission a success
2. is the HTTP status 470 or 471? is there an errors section in the JSON body? if ANY of this is YES, then we display validation error messages, and the submission is considered a failure
3. is the returned UUID different to the submitted one? what about the timestamps? if ANY of this is YES, then we fail the submission due to mismatch
4. if we get to this point, then we know there's an error but we don't know exactly which kind of error occurred. so we spit out the HTTP status code with "unable to complete form action"
The HTTP status 0 is often due to a lack of any HTTP header being received at all (as any real header would usually specify a non-0 status code). This can mean that the connection was disrupted or timed out before the server could begin sending a response.