XHR(2): suggestions for enhancing synchronous mode
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.
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
suggestions to remedy the issues with sync calls:
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
argument could be added to XHR.open() or XHR.send().
Note that this
new timeout parameter could also apply to asynchronous
2) React to Stop
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.
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
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)
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?