168128 - XMLHttpRequest does not always use blocking send even if async was specifies as false in the call to open

Status: RESOLVED WORKSFORME

(Core :: XML, defect)

Description

[Aatu Koskensilta]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0

When an XMLHttpRequest is opened and the async parameter is given
as false, the send does not always block, i.e.

var r = new XMLHttpRequest;
r.open("GET", "http://foo.net/blah", false);
r.send();
// Sometimes responseText here is undefined, and the 
// readyState is not 4, but 1 (it seems it could also be 2
// but I haven't been able to verify that this is indeed the
// case).



Reproducible: Sometimes

Steps to Reproduce:
(Start many threads, e.g. trough events, and issue synchronous XMLHttpRequests 
from all of these. Preferrably one thread should be continously sending
a request after request).
Actual Results:  
Sometimes send returns even though the request seems not to have been completed,
i.e. a reply is not available.

Expected Results:  
Send should block until a reply is available.

Comment 1

[Aatu Koskensilta]

I'm working on producing a simple testcase.

Comment 2

[Michael Lefevre]

reporter (Aatu): can you reproduce this bug with a recent build of mozilla (for
example, 1.2beta)? if so, please comment again with details, and that testcase
would be great. if not, please resolve this bug as WORKSFORME. thanks.

Comment 3

[Aatu Koskensilta]

Due to the non-deterministic nature of this bug (it seems to be highly
sensible to nerwork load, i.e. latency and such issues) I can't tell for sure
whether Mozilla1.2beta fixes this bug. When I test the code on my development
machine the bug does not occur. However, a test user reports that it *does*.
I'll try to verify whether or not this is the case (the test user is not
technology savvy and is not all that reliable in his reports).

I've been under very heavy workload lately, and thus have not been able to
produce a testcase. I will have to, if Mozilla1.2beta does not have this fixed
already, as I need XMLHttpRequest in my application for RPC, and we're
approaching final stages in our development.

There are workarounds, but all of these (that I can think of) require huge
refactoring of code. For example, it would be possible to implement a RPC
procedure as follows:

function RPCall(url, continuation)
{
  XMLHttpRequest request;
  request.open(...);
  ...
  request.onload = 
  function ()
  {
    continuation(request.responseText);
  }
}

However, this requires that code like

{
  ...
  ...
  var result = RPCall("/foo?arg1=hello");
  ...<loads of code1>...
  var result2 = RPCall("/bar?arg1=fiddle");
  ...<loads of code2>...
}

be transformed into

{
  ...
  RPCall("foo?arg1=hello",
  function (result)
  {
    ...<loads of code 1>...
    RPCall("bar?arg2=fiddle",
    function (result2)
    {
    });
  });
}

This is not a very elegant solution and does not make maintaining code any easier.

I'll come back to this within a few hours as I get more information about
Mozilla1.2beta.

Comment 4

[Aatu Koskensilta]

I went to the tester who reported this error occuring even in 1.2beta and
tried it myself. I could not produce this bug no matter what I tried. This does
not by itself mean that the bug is gone. I'll do some more testing before
changing bug status to WORKSFORME.

Comment 5

[Aatu Koskensilta]

The bug is still there, although it occurs *much* more infrequently than before.
This has perhaps to something to do with the overall speed increase in
Mozilla1.2beta. I'll start working on the testcase again.

Comment 6

[Manos Batsis]

I am trying to extend the Document.prototype.load method to allow sync/async
loading (using a Document.prototype.async property lik IE). The method works
great for asyncronous loading but the internal syncronous XMLHttpRequest call to
send() always returns before the document completes loading although the async
parameter is set to false.

Comment 7

[mikel_maron]

I have produced a test case for this bug...

http://alumni.cse.ucsc.edu/~mikel/xmlhttprequest/client.html

Comment 8

[Michael Lefevre]

well I don't pretend to understand what this is about, but the testcase seems to
be doing whatever it isn't supposed to using 2003010108/trunk/win2k, so marking
confirmed.

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I am unable to reprodue this so closing as worksforme. If you still see this
with the latest builds, feel free to reopen and please provide as much details
as you can so I could reproduce.

I tested with the testcase from mikel_maron, going from the default 2000 timeout
all the way to 0 and never saw any problems. Please note that with shorter
timeouts the layout seems to happen spuriusly but this is expected.

Comment 10

[Bart Friederichs]

It seems also to happen when using multiple windows. I have a testcase that does
it *always*. 

1. Open http://www.friesoft.nl/xmlhttpreq-testcase/testcase.php
2. Click on the dateselector, right next to the input field.
3. Select a date.

Then, the script will close the popup window and class 'updateCounters'
afterwards. That updateCounters is a function that uses XMLHttpRequest.

Note: the testcase is a stripped version of an actual application. Some code
might raise more errors, because of missing elements.

Comment 11

[steve.m.miller]

I have been dealing with this bug all day today...The only contribution I have is that if you call an alert anywhere after calling .send() but before you check .readyState, readyState returns 4 correctly