W3C home > Mailing lists > Public > public-webapi@w3.org > February 2007

XHR(2): suggestions for enhancing synchronous mode

From: Mike Wilson <mikewse@hotmail.com>
Date: Thu, 22 Feb 2007 23:06:41 +0100
Message-ID: <BAY116-DAV68C5DCF2C40B4E8EC65C7A48F0@phx.gbl>
To: <public-webapi@w3.org>
Message-ID: <038801c756cd$bb4a94a0$0a01a8c0@mikedeskxp>
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
Received on Friday, 23 February 2007 15:38:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT