XHR(2): suggestions for enhancing synchronous mode

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

XHR(2): suggestions for enhancing synchronous mode

mikewse
In its current implementations XMLHttpRequest's synchronous mode is often unusable due to its grave implications of possibly hanging the browser window. This can happen as there is no mechanism for cancelling a synchronous request after it has been started, so if the server hangs so does the XHR call and this leads to the whole browser window locking up.
The synchronous mode can be very valuable to Ajax application programmers that make stateful client applications. Examples include simplifying your code, avoiding the extra boilerplate code with asynchronous handler functions, and if you want your client application to make a request to the server in the onunload handler (when leaving the current page) your best option is usually to use sync mode as it will block the page unload until the response arrives.
Below are suggestions to remedy the issues with sync calls:
 
1) Timeout
Make it possible to specify a timeout so the XHR.send() call exits after this time has passed even if no response has arrived. It would be appropriate to throw an exception, like the existing NETWORK_ERR or maybe a new TIMEOUT_ERR.
The timeout argument could be added to XHR.open() or XHR.send().
Note that this new timeout parameter could also apply to asynchronous requests.
 
2) React to Stop button
It should be possible for the user to abort a synchronous XHR request that is blocking the browser window, by clicking the Stop button. It should make the blocking XHR.send() call throw an exception, like the existing NETWORK_ERR or maybe a new ABORTED_ERR.
Before aborting the call it may be suitable for the browser to prompt for confirmation, f ex "A script is waiting for a remote resource. Do you want to abort?".
This one is sort of difficult to write the specification text for, but maybe something like this could do: "if the user agent has a mechanism that allows the user to abort loading the current page, then the same mechanism should cancel an ongoing XHR request".
 
3) Process UI events
In current implementations a synchronous XHR.send() blocks all event handling in a browser window, including UI events for updating the browser window, until the response has arrived and the event thread returns to the main event loop. This causes the browser window not to redraw its contents after being obscured, and not to respond to any navigation commands (back, forward, etc) while blocking in a synchronous request.
This should be updated so the browser window is expected to handle window events while blocking in a  sync call. We probably don't want to trigger event handlers in the current document so the handled events should be limited to window repainting and browser (not page) commands.
This feature is needed to make it possible to click the Stop button (above) as everything in the browser UI is otherwise unresponsive.
Again, this one may be hard to fit in the W3C text, but it would be great to standardize this behaviour in some form. Ideas?
 
Best regards
Mike Wilson