310337 - XMLHttpRequest async activity is blocked by JavaScript loops

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[chris.mellon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Noticed this when attempted to simulate "blocking with timeout" using a while
loop. While the while loop is running, the status if the XMLHTTPRequest object
won't update. From the information I found while searching Bugzilla for other
instances of this bug, I'm guessing that the JS thread is blocking events from
the network that would be used to update the XMLHttpRequest object.

Reproducible: Always

Steps to Reproduce:
Run attached code
Actual Results:  
request times out

Expected Results:  
Request should have completed and the loop should have exited without timing out.

Comment 1

[chris.mellon]

Attachment: testcase showing bug

Comment 2

[Benjamin Smedberg]

I'm almost positive this is by design and not a bug. But perhaps if there are no
JS load listeners on the xmlhttprequest this could be done without breaking
run-to-completion. Anyway, the "correct" way to write this code is to use a load
listener.

Comment 3

[chris.mellon]

I don't understand how this can be considered correct behavior. Note that IE (I
haven't tested KHTML based browsers) does this correctly. 

You cannot implement the same logic using listeners, because you can't block on
an event within JavaScript. Queing calls to the event listener would be
acceptable (although IE doesn't), but imo blocking the network activity and
object updates, which do not involve breaking flow of control and won't violate
run to completion, isn't.

Comment 4

[robinpelgrim]

IE also does not handle events when being in a while loop.

What is missing in XMLHttpRequest is a method to resync to asynchronous request.
In that respect the javascript design is very poor, it lacks a sleep function,
so other events can be handled.

In IE6.0 there was a workaround to do this by opening a modal dialog for a short time. It blocks a function whitout breaking the flow of control and other events are handled.
(IE7.0 doesn't support this anymore).

When looking to the XMLHttpRequest object a 'resync' method should be added so at a certain point in your function you can wait for the request to finish.
Callback functions (event listeners) aren't suitable for that.

In many aspects the design is poor for javascript and it's standard objects like XMLHttpRequest.

I hope there will be some improvements in the near future so real applications can be developed with javascript (in a browser). 

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yeah, this is invalid.  JS run-to-completion semantics require that we not actually finish the request here...

Comment 6

[Darin Fisher]

Just break up lengthy JS loops using setTimeout.  Also, the IE modal dialog trick will likely work once bug 326273 is fixed.

Comment 7

[robinpelgrim]

XMLHttpRequest has async = false (synchronous data requests).
XMLHttpRequest has async = true (asynchronous data requests).
XMLHttpRequest has abort() for aborting asynchronized data requests.

XMLHttpRequest just MISSES resync() (or javascript MISSES sleep()).

It is not possible to wait in a function for a data request to finish:

-------------------------------------------------------------
function userAction() {
   WaitForRequestIsReady(previousASyncXMLHttpRequest);
   doSomeThingForTheUser();
}

There is no way to write the WaitForRequestIsReady function in javascript.
(SetTimeout is NOT suitable for that).
-------------------------------------------------------------
Writing an (AJAX?) application without the resync or sleep becomes very complex when only using callback functions. I just do not understand why the javascript possibilities (in the browser) are so bad (compared to Java/C# etc.).
It's sometimes a real struggle to get things properly done in Javascript / HTML.

Why do I need XUL for that?

Comment 8

[Brendan Eich [:brendan]]

(In reply to comment #7)
> XMLHttpRequest has async = false (synchronous data requests).
> XMLHttpRequest has async = true (asynchronous data requests).
> XMLHttpRequest has abort() for aborting asynchronized data requests.
> 
> XMLHttpRequest just MISSES resync() (or javascript MISSES sleep()).

There is no standard sleep, and browsers do not agree on execution model beyond the single-threaded run-to-completion semantics I intentionally created back in Netscape 2.  This is still the preferred model, by Opera, Apple, and Mozilla at least.

> It is not possible to wait in a function for a data request to finish:
> 
> -------------------------------------------------------------
> function userAction() {
>    WaitForRequestIsReady(previousASyncXMLHttpRequest);
>    doSomeThingForTheUser();
> }
> 
> There is no way to write the WaitForRequestIsReady function in javascript.
> (SetTimeout is NOT suitable for that).

Generator function (see http://weblogs.mozillazine.org/roadmap/) support coming in Firefox 2 may help, but that is only coming in Firefox 2 this year (generators are slated to be in Edition 4 of ECMAScript).

> -------------------------------------------------------------
> Writing an (AJAX?) application without the resync or sleep becomes very complex
> when only using callback functions. I just do not understand why the javascript
> possibilities (in the browser) are so bad (compared to Java/C# etc.).

Because browsers are not servers, and the mass of content authors are not and never will be ready for threads.  Are you sure you are?  At any rate, browsers including very small ones are not, but the chief objection is that the execution model should be run-to-completion, for the target programmer audience skill set.

> It's sometimes a real struggle to get things properly done in Javascript /
> HTML.
> 
> Why do I need XUL for that?

You don't.  Have you considered an AJAX library, in particular, MochiKit (http://mochikit.org/)?  It has nice twisted-inspired Deferred objects to help manage callbacks.

At any rate, a bugzilla.mozilla.org report is not the place to call for more complex execution models in browsers.

/be