Issues with IE & Prototype/AJAX

Discussion in 'Javascript' started by Steve-O, Aug 2, 2006.

  1. Steve-O

    Steve-O Guest

    The following code works great in FireFox, Opera, Netscape, Safari, and
    Gecko, but NOT IE. Why?

    I tried using 'native' js with setInterval and setTimeout, but I get
    the same result. My IE security settings are not an issue.

    Anyone have any insight on this?

    Thanks!
    -sh
    *****************************************************************
    // JavaScript Document
    var ud1 = new PeriodicalExecuter(getIncrementer, 5);
    var ud2 = new PeriodicalExecuter(getMicrotime, 5);

    function getIncrementer()
    {
    var url = 'filter.htm';
    var myAjax = new Ajax.Request( url, { method: 'get', onComplete:
    showMyData });
    }

    function getMicrotime()
    {
    var url = 'filter2.htm';
    var myAjax2 = new Ajax.Request( url, { method: 'get', onComplete:
    showMicrotime });
    }

    function showMyData(req)
    {
    //put returned Text/XML in the textarea
    $('my_div').innerHTML = req.responseText;
    }

    function showMicrotime(req)
    {
    //put returned Text/XML in the textarea
    $('microtime_div').innerHTML = req.responseText;
    }
    Steve-O, Aug 2, 2006
    #1
    1. Advertising

  2. Steve-O

    RobG Guest

    Steve-O wrote:
    > The following code works great in FireFox, Opera, Netscape, Safari, and
    > Gecko, but NOT IE. Why?


    For some udisclosed value of 'works' and 'not (works)'.


    > I tried using 'native' js with setInterval and setTimeout, but I get
    > the same result. My IE security settings are not an issue.


    prototype.js is about 1,800 lines of code and you give no hints as to
    where the error might be. Post the 'native' js version and you might
    get an answer - or ask in a prototype.js news group or forum.

    [...]


    --
    Rob
    RobG, Aug 3, 2006
    #2
    1. Advertising

  3. Steve-O

    Guest

    Steve-O wrote:
    > The following code works great in FireFox, Opera, Netscape, Safari, and
    > Gecko, but NOT IE. Why?
    >
    > I tried using 'native' js with setInterval and setTimeout, but I get
    > the same result. My IE security settings are not an issue.
    >
    > Anyone have any insight on this?
    >
    > Thanks!
    > -sh
    > *****************************************************************
    > // JavaScript Document
    > var ud1 = new PeriodicalExecuter(getIncrementer, 5);
    > var ud2 = new PeriodicalExecuter(getMicrotime, 5);
    >
    > function getIncrementer()
    > {
    > var url = 'filter.htm';
    > var myAjax = new Ajax.Request( url, { method: 'get', onComplete:
    > showMyData });
    > }
    >
    > function getMicrotime()
    > {
    > var url = 'filter2.htm';
    > var myAjax2 = new Ajax.Request( url, { method: 'get', onComplete:
    > showMicrotime });
    > }
    >
    > function showMyData(req)
    > {
    > //put returned Text/XML in the textarea
    > $('my_div').innerHTML = req.responseText;
    > }
    >
    > function showMicrotime(req)
    > {
    > //put returned Text/XML in the textarea
    > $('microtime_div').innerHTML = req.responseText;
    > }


    setTimeout sometimes catches me because I forget that they are separate
    threads and that they only run once. If you want to make a sort of
    do-events style for-loop type structure using setTimeout instead, you
    need two functions.

    The first starts it going, eg:
    <script> setTimeout(code, time); </script>

    the second has to decide whether to set it going again:
    <script>
    DoStuff()
    if (keepgoing) setTimeout(code, time);
    </script>

    careful that you keep track of if the loops is current executing, eg
    with a global variable or something more refined. Else someone might
    start the timer twice and you'll get two loops that each spawn two new
    ones when they finish. Generally doubles the framerate of whatever you
    are updating, but not in a good way.

    hth

    http://darwinist.googlepages.com/htmldesktop.html
    , Aug 3, 2006
    #3
  4. wrote:
    <snip>
    > ... I forget that they are separate threads ...


    You should as javascript is not multithreaded, so they are _not_
    separate threads.

    Richard.
    Richard Cornford, Aug 3, 2006
    #4
  5. Steve-O

    Ray Guest

    Richard Cornford wrote:
    > wrote:
    > <snip>
    > > ... I forget that they are separate threads ...

    >
    > You should as javascript is not multithreaded, so they are _not_
    > separate threads.


    When you send an AJAX request using Prototype, isn't it done using a
    separate thread? I know what you mean about JS (the language) being not
    multithreaded though.

    >
    > Richard.
    Ray, Aug 3, 2006
    #5
  6. Ray wrote:
    > Richard Cornford wrote:
    >> wrote:
    >><snip>
    >>> ... I forget that they are separate threads ...

    >>
    >> You should as javascript is not multithreaded, so they are _not_
    >> separate threads.

    >
    > When you send an AJAX request using Prototype, isn't it done using a
    > separate thread?


    I would never use Protoytpe.js, I know javascript. The XML HTTP request
    objects (at least when making asynchronous requests) must be operating
    in what is effectively a separate thread (but they are likely written
    in C++). The handling of the response by javascript is not
    multithreaded; no executing javascript in the same environment will be
    interrupted by/overlap with the response from and XML HTTP request
    object and the handling of that response will not be interrupted
    by/overlap with event handling code or setTimeout/Interval triggered
    code (the latter must wait until the handling of the XML HTTP response
    comes to an end).

    > I know what you mean about JS (the language) being not
    > multithreaded though.


    Good, VK is likely to try to make out the javascript is multithreaded
    (at least he has often done so in the past) but nobody else is that
    foolish.

    Richard.
    Richard Cornford, Aug 3, 2006
    #6
  7. Steve-O

    Ray Guest

    Richard Cornford wrote:
    <snip>
    > The handling of the response by javascript is not
    > multithreaded; no executing javascript in the same environment will be
    > interrupted by/overlap with the response from and XML HTTP request
    > object and the handling of that response will not be interrupted
    > by/overlap with event handling code or setTimeout/Interval triggered
    > code (the latter must wait until the handling of the XML HTTP response
    > comes to an end).


    Ah, I didn't know this part. Thanks! That's good to know.

    <snip>
    Ray, Aug 3, 2006
    #7
  8. Steve-O

    Ray Guest

    Why not Prototype? (Was: Re: Issues with IE & Prototype/AJAX)

    Richard Cornford wrote:
    > I would never use Protoytpe.js, I know javascript. <snip>


    What's wrong with Prototype? What do you think of other libraries like
    Dojo toolkit or X ?

    Thanks,
    Ray

    > Richard.
    Ray, Aug 3, 2006
    #8
  9. Re: Why not Prototype? (Was: Re: Issues with IE & Prototype/AJAX)

    On 03/08/2006 12:05, Ray wrote:

    > Richard Cornford wrote:
    >
    >> I would never use Protoytpe.js, I know javascript. <snip>

    >
    > What's wrong with Prototype?


    There has been at least one thread dedicated to criticism of the
    Prototype library[1]. Feel free to browse the archives[2]. :)

    > What do you think of other libraries like Dojo toolkit or X ?


    I'm not trying to speak for Richard, but his answer is highly likely to
    be negative; he dislikes monolithic libraries, as do some other regulars
    in this group. You will quickly realise that from browsing the
    archives[3]. Perhaps he has specific criticism, though.

    I've never used any of them, myself, and only glanced at Prototype long
    enough to dislike it.

    Mike


    [1] prototype.js criticism 2006-03-20 07:26:45 GMT
    <>
    <http://groups.google.co.uk/group/comp.lang.javascript/browse_thread/thread/b699522a97d26a6d/5d5110a25cd79c2e?lnk=st&q=&rnum=2&hl=en#5d5110a25cd79c2e>

    [2] Google Groups search results for:
    group:comp.lang.javascript prototype library wrong | bad | evil
    <http://groups.google.co.uk/groups?lnk=hpsg&hl=en&q=group%3Acomp.lang.javascript+prototype+library+wrong+%7C+bad+%7C+evil>

    [3] Google Groups search results for:
    group:comp.lang.javascript author:"Richard Cornford" libraries
    <http://groups.google.co.uk/groups/search?hl=en&q=group%3Acomp.lang.javascript+author%3A%22Richard+Cornford%22+libraries&qt_s=Search>
    Michael Winter, Aug 3, 2006
    #9
  10. Steve-O

    Ray Guest

    Re: Why not Prototype? (Was: Re: Issues with IE & Prototype/AJAX)

    Michael Winter wrote:
    > On 03/08/2006 12:05, Ray wrote:
    >
    > > Richard Cornford wrote:
    > >
    > >> I would never use Protoytpe.js, I know javascript. <snip>

    > >
    > > What's wrong with Prototype?

    >
    > There has been at least one thread dedicated to criticism of the
    > Prototype library[1]. Feel free to browse the archives[2]. :)

    <snip>

    Thanks Michael!! That's going to be educational for me :)

    Cheers
    Ray
    Ray, Aug 3, 2006
    #10
  11. Re: Why not Prototype? (Was: Re: Issues with IE & Prototype/AJAX)

    Ray wrote:
    > Richard Cornford wrote:
    >> I would never use Protoytpe.js, I know javascript.

    ><snip>
    > What's wrong with Prototype?


    It would take too long to explain properly, but it appears to mostly
    come down to the authors not really knowing javascript well enough to
    appreciate it as a language and instead trying to twist it into
    something more like a language that they did appreciate. There is a
    Catch 22 in that attitude, in that they would have had to learn to
    appreciate javascript before being in a position to do a good job
    twisting it to be like their preferred language, at which point they
    would no longer have seen a need to make the effort. The inevitable
    result of this contradiction is a large collection of interdependent,
    brittle, environment limited, inefficient and bulky code.

    > What do you think of other libraries like
    > Dojo toolkit or X ?


    Libraries are mostly about code re-use, but as a strategy for code
    re-use they do not fit well with the nature of browser scripting.
    Alternative strategies offer equivalent levels or code re-use (or
    better) and are better suited to the necessity of having all the
    executable code used downloaded to the browser.

    Richard.
    Richard Cornford, Aug 3, 2006
    #11
  12. Steve-O

    Guest

    Richard Cornford wrote:
    > wrote:
    > <snip>
    > > ... I forget that they are separate threads ...

    >
    > You should as javascript is not multithreaded, so they are _not_
    > separate threads.


    What is it then when you fire one or more setTimeout() calls? They
    behaves very differently to just continuing with code (other events
    will occur, such as a display refresh, for example) and you can have it
    fire on user-events, generating multiple timing loops occuring at once.
    What is this if not threads?

    > Richard.
    , Aug 4, 2006
    #12
  13. Steve-O

    RobG Guest

    wrote:
    > Richard Cornford wrote:
    > > wrote:
    > > <snip>
    > > > ... I forget that they are separate threads ...

    > >
    > > You should as javascript is not multithreaded, so they are _not_
    > > separate threads.

    >
    > What is it then when you fire one or more setTimeout() calls? They
    > behaves very differently to just continuing with code (other events
    > will occur, such as a display refresh, for example) and you can have it
    > fire on user-events, generating multiple timing loops occuring at once.
    > What is this if not threads?


    A queue.

    The browser itself may be multi-threaded and most seem to be - they can
    fire many HTTP requests and download various parts of a document
    simultaneously. The script element's 'defer' attribute seems to have
    been inspired by this behaviour, allowing a browser to download other
    resources while downloading and executing the script.

    Most browsers will not update the screen while a script is running,
    which makes sense - why constantly update the screen while DOM
    manipulation is occurring? It makes much more sense to wait until all
    modifications have occurred and then re-paint the screen once.

    In JavaScript, only one thread runs at a time. It has already been
    categorically stated in this thread that one JavaScript process can't
    interrupt another, therefore neither setTimeout or setInterval can
    interrupt an executing process - they must wait until whatever process
    is running completes before they run. Otherwise it would be very
    simple to use setTimeout to stop an endless loop, e.g.:

    var _gobal = this;
    function stopProcess(process) {
    setTimeout(function() _global[process] = null;}, 1000)
    }
    function endlessLoop() {
    stopProcess(arguments.callee.name);
    while(true){}
    }

    If the above did work (and I guarantee it doesn't) then stopProcess()
    should be able to cancel the endless loop - but it can't because as
    long as endlessLoop() runs, no other script will get a look-in. If it
    were possible, I imagine it would be used extensively in debugging.

    Of course the *browser* may (and some do) provide another thread that
    monitors and optionally cancels a an executing JavaScript process, but
    that is a host environment thread, not a second (or third or fourth)
    JavaScript thread.


    --
    Rob
    RobG, Aug 4, 2006
    #13
  14. Steve-O

    Ray Guest

    Re: Why not Prototype? (Was: Re: Issues with IE & Prototype/AJAX)

    Richard Cornford wrote:
    <snip>
    > > What do you think of other libraries like
    > > Dojo toolkit or X ?

    >
    > Libraries are mostly about code re-use, but as a strategy for code
    > re-use they do not fit well with the nature of browser scripting.
    > Alternative strategies offer equivalent levels or code re-use (or
    > better) and are better suited to the necessity of having all the
    > executable code used downloaded to the browser.


    Thanks Richard,

    Wondering what the alternative strategies to code reuse are, if not
    libraries? The moment you separate your oft-used code into a separate
    js file and organize them into functions/classes, you have a library,
    don't you?

    Regards,
    Ray

    >
    > Richard.
    Ray, Aug 4, 2006
    #14
  15. Steve-O

    Guest

    RobG wrote:
    > wrote:
    > > Richard Cornford wrote:
    > > > wrote:
    > > > <snip>
    > > > > ... I forget that they are separate threads ...
    > > >
    > > > You should as javascript is not multithreaded, so they are _not_
    > > > separate threads.

    > >
    > > What is it then when you fire one or more setTimeout() calls? They
    > > behaves very differently to just continuing with code (other events
    > > will occur, such as a display refresh, for example) and you can have it
    > > fire on user-events, generating multiple timing loops occuring at once.
    > > What is this if not threads?

    >
    > A queue.
    >
    > The browser itself may be multi-threaded and most seem to be - they can
    > fire many HTTP requests and download various parts of a document
    > simultaneously. The script element's 'defer' attribute seems to have
    > been inspired by this behaviour, allowing a browser to download other
    > resources while downloading and executing the script.
    >
    > Most browsers will not update the screen while a script is running,
    > which makes sense - why constantly update the screen while DOM
    > manipulation is occurring? It makes much more sense to wait until all
    > modifications have occurred and then re-paint the screen once.
    >
    > In JavaScript, only one thread runs at a time. It has already been
    > categorically stated in this thread that one JavaScript process can't
    > interrupt another, therefore neither setTimeout or setInterval can
    > interrupt an executing process - they must wait until whatever process
    > is running completes before they run. Otherwise it would be very
    > simple to use setTimeout to stop an endless loop, e.g.:
    >
    > var _gobal = this;
    > function stopProcess(process) {
    > setTimeout(function() _global[process] = null;}, 1000)
    > }
    > function endlessLoop() {
    > stopProcess(arguments.callee.name);
    > while(true){}
    > }
    >
    > If the above did work (and I guarantee it doesn't) then stopProcess()
    > should be able to cancel the endless loop - but it can't because as
    > long as endlessLoop() runs, no other script will get a look-in. If it
    > were possible, I imagine it would be used extensively in debugging.
    >
    > Of course the *browser* may (and some do) provide another thread that
    > monitors and optionally cancels a an executing JavaScript process, but
    > that is a host environment thread, not a second (or third or fourth)
    > JavaScript thread.


    How very interesting. I had to write my own infinite loop examples to
    understand what you mean, but see how it distinguishes a queue from the
    thread. Thanks for the info.

    For many practical purposes, you can have the equivalent of multiple
    loops running at once, with the gui still responsive while they're
    running, using timeouts.

    ---
    http://darwinist.googlepages.com/htmldesktop.html
    (A free, open-source web-based IDE, windowing system, and desktop
    environment, in 31kB of html and javascript.)
    >
    > --
    > Rob
    , Aug 4, 2006
    #15
  16. Steve-O

    Matt Kruse Guest

    Re: Why not Prototype? (Was: Re: Issues with IE & Prototype/AJAX)

    Ray wrote:
    > Wondering what the alternative strategies to code reuse are, if not
    > libraries? The moment you separate your oft-used code into a separate
    > js file and organize them into functions/classes, you have a library,
    > don't you?


    Search the google archives of this group for "cornford libraries" and you'll
    find many debates on the topic, often with me ;)

    --
    Matt Kruse
    http://www.JavascriptToolbox.com
    http://www.AjaxToolbox.com
    Matt Kruse, Aug 4, 2006
    #16
  17. Steve-O

    Matt Kruse Guest

    Matt Kruse, Aug 4, 2006
    #17
  18. Steve-O

    Ray Guest

    Ray, Aug 4, 2006
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. June Lee
    Replies:
    2
    Views:
    800
    Jim Cobban
    Apr 13, 2008
  2. Prototype AJAX Issues

    , Mar 3, 2006, in forum: Javascript
    Replies:
    2
    Views:
    81
  3. Replies:
    9
    Views:
    186
    Thomas 'PointedEars' Lahn
    May 26, 2006
  4. Replies:
    3
    Views:
    264
  5. javascript fish
    Replies:
    0
    Views:
    169
    javascript fish
    Oct 11, 2008
Loading...

Share This Page