Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Asynchronous JavaScript

I am building a Web App which relies heavily on asynchronous
javascript (XMLHttpRequest).

It works a beautifully in IE7 and FF 2+ , but in IE6 (6.0.2900.2180
((sp2)) even though the asynchronous flag is set to true the call is
synchronous and doesn=92t fork!! This problem is sporadic, only
happening on some peoples PCs some of the time and not others (with
the same full version as seen in Help->About). My code to test and
demonstrate this is as follows:.

The variables onExitRoot and callerHasLeft are used to test if the
Http Request was processed asynchronously..

Any ideas why this doesn=92t work on some versions of IE6=85

    var onExitRoot = false;
    var callerHasLeft = false;

    var req = CTalk.getHTTPReq(); //get XMLHttpRequest or throw exception
if not supported
    var reqStage1OK = false;

    var to = setTimeout(function() { req.abort(); if(reqStage1OK)
CTalk.displayErrOnCon(CTalk._M_ERRCON_TYPE_INCOMPLETE); else
CUi.displayMsg("Error Connecting to X!",true); },

    var url = "req.php?CID=3D" + escape(CTalk._M_CLIENT_ID) + "&M=3D" +
escape(mtype + param);
    CUtil.log("opening ASync req: " + url);"GET", url, true);

    req.onreadystatechange = function()
                CUtil.log("sendAsyncReq state : " + req.readyState);

                    reqStage1OK = true;
                else if(req.readyState=3D=3D4)
                        CUtil.log("HTTP 200 from sendAsyncReq, done.");
                        CUtil.log("HTTP/1.1 ERR from sendAsyncReq.");
                        try { CUi.displayMsg("Error",true); req.abort(); } catch(err) {}
        } catch(e) { CUtil.log(e.message); alert("ERR: " + e.message); }

    CUtil.log("About to send data request");

    if(onExitRoot && !callerHasLeft)
        CUtil.log("Async not working!!");
        //IF we get here async didn't work!!
                //THis case is hit in IE6 on one call and then on a
subsiquent call it is not hit.

    callerHasLeft = true;
} catch(e) { CUtil.log(e.message); alert("ERROR: " + e.message); }

Re: As

JT wrote:
Quoted text here. Click to load it

I don't know what you mean my "same full version" but mine says

Since I received my PC a couple of years ago, Microsoft Update has
applied quite a few fixes affecting IE, and that version probably
doesn't identify exactly which combination I have.

Over this period, the behaviour of my IE6 has departed radically from
that of colleagues who don't run Microsoft/Windows update. The variation
is so great that two different IE6's, using the same CGI script, erase
different files when exactly the same button is clicked. (In later IE6,
only the button clicked gets submitted, so the correct file is deleted;
in earlier IE6, all of the delete buttons are submitted, so depending
how you wrote your CGI script, you either erase ALL possible files, or
the first, or the last. I was "lucky", and erased only the last, which
happened to be an extreme test case).

So don't expect all IE6's to behave the same, perhaps not even when
their version is the same.

Steve Swift

Re: As

JT wrote:
Quoted text here. Click to load it

There is no such thing to begin with.  All known ECMAScript implementations
are single-threaded.  window.setTimeout()/setInterval(), which can emulate
threads to a certain extent, are host-defined features that are not part of
any current JavaScript version (1.4+) and have never been part of JScript.

Quoted text here. Click to load it

That is your *assumption*.  Your code shows that your assumption is at fault
here, not necessarily IE/MSHTML.

Quoted text here. Click to load it

There is the root of your mistake.  You are assuming that when onExitRoot ==
true the event listener must have exited.  But the nature of asynchronous
(request-response) handling is that things happen (here: seemingly) in
parallel, and that req.send(null) does _not_ wait for the listener to be
called.  So it is entirely possible that the assignment did take place when
you evaluate the property value.

Since you always set `callerHasLeft' to `false' before req.send(null)
always, the second operand of the AND operation is always true and so does
not matter.

    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

Site Timeline