Ajax in sync mode works with IE, does not work with Firefox

Discussion in 'Javascript' started by zalek, Aug 29, 2008.

  1. zalek

    zalek Guest

    I am writing application with Ajax in sync mode - xmlHttp.open("GET",
    url, false).
    I noticed that in FireFox handler doesn't starts. It starts when I use
    xmlHttp.open("GET", url,true).
    I need to use it in sync mode. Any ideas what can I do?

    Thanks,

    Zalek.
     
    zalek, Aug 29, 2008
    #1
    1. Advertising

  2. zalek

    Jorge Guest

    On Aug 29, 3:55 am, zalek <> wrote:
    > I am writing application with Ajax in sync mode - xmlHttp.open("GET",
    > url, false).
    > I noticed that in FireFox handler doesn't starts. It starts when I use
    > xmlHttp.open("GET", url,true).
    > I need to use it in sync mode. Any ideas what can I do?
    >


    The callback won't get called for synchronous XHR requests (there's no
    need to).

    But (AFAIK) nothing prevents you from calling it ("by hand") if you
    need to, inmediatly after the .open(,,false) :

    //xmlHttp.onreadystatechange= myCallback;
    xmlHttp.open("GET", url, false);
    myCallback();

    --Jorge.
     
    Jorge, Aug 29, 2008
    #2
    1. Advertising

  3. zalek

    GArlington Guest

    On Aug 29, 2:55 am, zalek <> wrote:
    > I am writing application with Ajax in sync mode - xmlHttp.open("GET",
    > url, false).
    > I noticed that in FireFox handler doesn't starts. It starts when I use
    > xmlHttp.open("GET", url,true).
    > I need to use it in sync mode.

    WHY do you need to make AJAX call "in sync mode"? IT will only stop
    doing anything else until it gets a response from the server...
    So, just DO NOT do anything else until you get a response...
    Or maybe I misunderstand what you are trying to do...
    > Any ideas what can I do?
    >
    > Thanks,
    >
    > Zalek.
     
    GArlington, Aug 29, 2008
    #3
  4. zalek

    optimistx Guest

    zalek wrote:
    > I am writing application with Ajax in sync mode - xmlHttp.open("GET",
    > url, false).
    > I noticed that in FireFox handler doesn't starts. It starts when I use
    > xmlHttp.open("GET", url,true).
    > I need to use it in sync mode. Any ideas what can I do?
    >
    > Thanks,
    >
    > Zalek.

    Is this correct:
    If the response for any reason does not come immediately but e.g. in 20
    seconds (or never!)
    the whole browser page is like dead, keyboard dead, mouse clicking has no
    effect, the user becomes angry and desperate, goes away from your page and
    never comes back. Or ...?
     
    optimistx, Aug 29, 2008
    #4
  5. zalek

    Steve Swift Guest

    GArlington wrote:
    > WHY do you need to make AJAX call "in sync mode"?


    It's the difference between "while you wait" and "drop it off and we'll
    call you when its ready". Many people prefer the "while you wait"
    approach. It's certainly simpler. For some processes, it is the only one
    that makes sense (for example, going to the dentists).

    Let's see how you get on at the next trip to the dentists if they say
    "Drop them off and we'll call you when they're ready". :)

    --
    Steve Swift
    http://www.swiftys.org.uk/swifty.html
    http://www.ringers.org.uk
     
    Steve Swift, Aug 29, 2008
    #5
  6. zalek

    Steve Swift Guest

    optimistx wrote:
    > If the response for any reason does not come immediately but e.g. in
    > 20 seconds (or never!) the whole browser page is like dead, keyboard
    > dead, mouse clicking has no effect, the user becomes angry and
    > desperate, goes away from your page and never comes back. Or ...?


    I'm writing a webpage where I'll be updating our database on every
    change of the checkboxes. I'll probably do this synchronously, so the
    check doesn't change state until the database confirms the update. This
    way I don't need a "Save" button. Our database has never failed, so no
    problem there. Occasionally the user will wonder why there's a slight
    delay in the checkbox responding, but I've seen worse delays caused by
    paging.

    If I did this asynchronously, the user might click on the checkbox,
    notice that it didn't change state instantly, and click it again.
    Handling this would be tricky (especially with my level of
    Javascript/Ajax skills) and wouldn't improve the user experience.

    Mind you, I'm the user as well.

    --
    Steve Swift
    http://www.swiftys.org.uk/swifty.html
    http://www.ringers.org.uk
     
    Steve Swift, Aug 29, 2008
    #6
  7. zalek

    optimistx Guest

    Steve Swift wrote:
    ....
    > Handling this would be tricky (especially with my level of
    > Javascript/Ajax skills) and wouldn't improve the user experience.


    It might be simpler to program than you think:

    http://yuiblog.com/blog/2006/04/04/synchronous-v-asynchronous/

    Why not set a flag, when the operation starts, and reset it, when complete?
    New requests are not accepted, if the flag is set.
     
    optimistx, Aug 29, 2008
    #7
  8. optimistx wrote:
    > zalek wrote:
    >> I am writing application with Ajax in sync mode -
    >> xmlHttp.open("GET", url, false).
    >> I noticed that in FireFox handler doesn't starts. It
    >> starts when I use xmlHttp.open("GET", url,true).
    >> I need to use it in sync mode. Any ideas what can I do?

    <snip>
    > Is this correct:
    > If the response for any reason does not come immediately but
    > e.g. in 20 seconds (or never!) the whole browser page is like
    > dead, keyboard dead, mouse clicking has no effect, the user
    > becomes angry and desperate, goes away from your page and
    > never comes back. Or ...?


    The user does not necessarily get to go away because synchronous
    requests can block the entire browser, so no navigation options are
    functional while the request is going on (obviously that can vary
    depending on the browser, but is true of IE 6 at absolute minimum). IE 6
    also crashes (with a 'do you want to tell Microsoft about this' dialog
    on XP) if you attempt to shut it down while a synchronous request is
    incomplete.

    It has appeared to me that the most common reason for using synchronous
    requests is precisely that they do block the browser, preventing any
    user interaction. The alternative would be to write code that
    managed/coordinated the multiple asynchronous triggers of code execution
    (user triggered events and HTTP XML responses), possibly involving
    actively blocking user input. Coding this type of thing is obviously
    more complex than allowing the side effects of a synchronous request to
    render it moot. But that does not mean the effort should not be part of
    any AJAX design.

    When AJAX was formally proposed the suggested architecture explicitly
    included a management/coordination/sequencing layer on the client
    labelled "the AJAX Engine". Over time the AJAX buzzword has been
    degraded to refer to any XML HTTP request based background loading
    system, and the "AJAX Engine" notion has mostly fallen by the wayside.
    Probably precisely because it is the difficult part to handle. The needs
    of asynchronous request management, coordination and sequencing will
    vary considerably between application contexts so no single general
    "AJAX Engine" would be appropriate; either being well over the top in
    some contexts and/or significantly inadequate it others. Thus while
    various 'frameworks' attempt to offer AJAX in reality they rarely go
    much beyond providing a wrapper around the HTTP XML request/response
    process and mostly leave "AJAX Engine" part of the problem to the
    problem to the individual using the 'framework'. (Though some (but
    nowhere near all) frameworks do include request queuing and even UI
    blocking facilities).

    Presented with a need, not having any 'solution' presented to them on a
    plate in various 'frameworks', and a task as complex as designing and
    creating their own "AJAX Engine" layer, it cannot be surprising that
    people would choose employing synchronous requests as there easiest way
    out of the situation. And without vigorous/rigorous QA testing
    (including the testing of responses to system/server and network
    failures of various sorts) it is entirely possible that they may get the
    impression of having gotten away with it.

    Richard.
     
    Richard Cornford, Aug 29, 2008
    #8
  9. Steve Swift meinte:

    > I'm writing a webpage where I'll be updating our database on every
    > change of the checkboxes. I'll probably do this synchronously, so the
    > check doesn't change state until the database confirms the update.


    Yuck. Somebody clicks, then wait (shall we click again?), then the box
    gets checked. Sounds like an atrocious user experience. Set the checkbox
    immediately. Then have an asynchronous XHR, and *if* an error occurs,
    reset the checkbox, issue a message, whatever. You can also collect
    checkbox clicks via a timeout and write several at once. This will -
    given a serious application - lower the stress on your webserver and
    database.

    > Occasionally the user will wonder why there's a slight
    > delay in the checkbox responding, but I've seen worse delays caused by
    > paging.


    He'll wonder becoause there are no delays with checkboxes. Normally.
    With paging it is common.

    > If I did this asynchronously, the user might click on the checkbox,
    > notice that it didn't change state instantly, and click it again.


    Not with the proper approach.

    > Handling this would be tricky


    No. Not more than any asynchronous communication. In short: synchronous
    XHR is useless.

    Gregor



    --
    http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
    http://web.gregorkofler.com ::: meine JS-Spielwiese
    http://www.image2d.com ::: Bildagentur für den alpinen Raum
     
    Gregor Kofler, Aug 29, 2008
    #9
  10. zalek

    Evertjan. Guest

    Steve Swift wrote on 29 aug 2008 in comp.lang.javascript:

    > GArlington wrote:
    >> WHY do you need to make AJAX call "in sync mode"?

    >
    > It's the difference between "while you wait" and "drop it off and we'll
    > call you when its ready". Many people prefer the "while you wait"
    > approach. It's certainly simpler. For some processes, it is the only one
    > that makes sense (for example, going to the dentists).
    >
    > Let's see how you get on at the next trip to the dentists if they say
    > "Drop them off and we'll call you when they're ready". :)


    var D = nice Dentist();

    while (holes in one)
    nextChild.dropOff(D);
    while (holes in one)
    nextSibling.dropOff(D);

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Aug 29, 2008
    #10
  11. zalek

    Jorge Guest

    On Aug 29, 1:50 pm, Steve Swift <> wrote:
    > optimistx wrote:
    > > If the response for any reason does not come immediately but e.g. in
    > > 20 seconds (or never!) the whole browser page is like dead, keyboard
    > > dead, mouse clicking has no effect, the user becomes angry and
    > > desperate, goes away from your page and never comes back. Or ...?

    >
    > I'm writing a webpage where I'll be updating our database on every
    > change of the checkboxes.  I'll probably do this synchronously, so the
    > check doesn't change state until the database confirms the update. This
    > way I don't need a "Save" button. Our database has never failed, so no
    > problem there. Occasionally the user will wonder why there's a slight
    > delay in the checkbox responding, but I've seen worse delays caused by
    > paging.
    >
    > If I did this asynchronously, the user might click on the checkbox,
    > notice that it didn't change state instantly, and click it again.
    > Handling this would be tricky (especially with my level of
    > Javascript/Ajax skills) and wouldn't improve the user experience.
    >


    You could change the checkbox's color to something else (red ?) while
    an (asynchronous) XHR takes place "in the background" to indicate that
    the change is still in progress. When the xhr finishes reset it back
    to the original color and the appropiate value (*).

    You could as well if you like overlay a semitransparent layer on top
    of the page, and show a spinning progress indicator (and a cancel
    button) while the XHR takes place.

    (*) But keep in mind that even though the XHR may report a status
    other than OK, it doesn't mean that the value was not properly set at
    the server side's DB : a possible error is that the request makes its
    way to the server, but the server's response never gets back to the
    browser : you'd need to query the DB with a second XHR in that case,
    but, that second XHR will most likely fail as well if there's a
    network problem going on...

    It's not that there's something wrong with synchronous XHRs per se,
    but because they may (and will, most likely, because of the way they
    are implemented in the current generation of browsers) hang the
    browser (It's not just your page's JavaScript execution that is
    halted, all other tabs are halted as well, and even the browser's UI)
    for quite a long time under even the slightest communication errors/
    problems/delays. Not so with asynchronous XHRs.

    --Jorge.
     
    Jorge, Aug 29, 2008
    #11
  12. zalek

    Steve Swift Guest

    Jorge wrote:
    > It's not that there's something wrong with synchronous XHRs per se,
    > but because they may (and will, most likely, because of the way they
    > are implemented in the current generation of browsers) hang the
    > browser


    Bearing in mind that I'm the user here, and I don't mind my browser
    hanging (it would certainly alert me to the fact that I had a much more
    important problem to work on than reading usenet).

    Imagine I was writing the exact same webpage as a GUI application in its
    own right. Every time a checkbox is clicked, the application has to
    update its datatabase. Imagine also that the application has the choice
    of handling this trivial update modally, or handling it asyncronously,
    re-enabling the interface whilst the update takes place (and possibly
    fails).

    If I were in the newsgroup for the GUI builder, they would be telling me
    that I was nuts to do it asyncronously, opening up a nightmare of
    problems that might occur if the user started playing with the UI whilst
    the update was pending.

    --
    Steve Swift
    http://www.swiftys.org.uk/swifty.html
    http://www.ringers.org.uk
     
    Steve Swift, Aug 31, 2008
    #12
  13. Hi Steve,

    > If I were in the newsgroup for the GUI builder, they would be telling me
    > that I was nuts to do it asyncronously, opening up a nightmare of
    > problems that might occur if the user started playing with the UI whilst
    > the update was pending.


    I agree whole-heartidly that business logic often dictates that there is
    absolutely no point in proceeding to B (or repeating A) until A has
    suceeded. But perhaps the best of both worlds would be something like a
    socket that is synchronous, yet has a timeout to catch those unacceptable
    delays? Something a la mode de: -
    http://manson.vistech.net/t3$examples/demo_client_web.html

    Username: TIER3_DEMO
    Password: QUEUE

    OTOH, the Ajax abort/cancel doesn't appear to do much more than tidy up the
    client and leave the server grinding?

    Cheers Richard Maher

    "Steve Swift" <> wrote in message
    news:...
    > Jorge wrote:
    > > It's not that there's something wrong with synchronous XHRs per se,
    > > but because they may (and will, most likely, because of the way they
    > > are implemented in the current generation of browsers) hang the
    > > browser

    >
    > Bearing in mind that I'm the user here, and I don't mind my browser
    > hanging (it would certainly alert me to the fact that I had a much more
    > important problem to work on than reading usenet).
    >
    > Imagine I was writing the exact same webpage as a GUI application in its
    > own right. Every time a checkbox is clicked, the application has to
    > update its datatabase. Imagine also that the application has the choice
    > of handling this trivial update modally, or handling it asyncronously,
    > re-enabling the interface whilst the update takes place (and possibly
    > fails).
    >
    > If I were in the newsgroup for the GUI builder, they would be telling me
    > that I was nuts to do it asyncronously, opening up a nightmare of
    > problems that might occur if the user started playing with the UI whilst
    > the update was pending.
    >
    > --
    > Steve Swift
    > http://www.swiftys.org.uk/swifty.html
    > http://www.ringers.org.uk
     
    Richard Maher, Aug 31, 2008
    #13
  14. zalek

    Jorge Guest

    On Aug 31, 8:06 am, Steve Swift <> wrote:
    >
    > Imagine I was writing the exact same webpage as a GUI application in its
    > own right.  Every time a checkbox is clicked, the application has to
    > update its datatabase. Imagine also that the application has the choice
    > of handling this trivial update modally, or handling it asyncronously,
    > re-enabling the interface whilst the update takes place (and possibly
    > fails).
    >
    > If I were in the newsgroup for the GUI builder, they would be telling me
    > that I was nuts to do it asyncronously, opening up a nightmare of
    > problems that might occur if the user started playing with the UI whilst
    > the update was pending.
    >


    Yes and no. It's not the same thing to disable a form's UI than to
    have the app's UI (either a standalone GUI app or a browser) hanged.

    You can test it here : http://preview.tinyurl.com/5eu3ll

    --
    Jorge.
     
    Jorge, Aug 31, 2008
    #14
  15. zalek

    Jorge Guest

    On Aug 31, 1:16 pm, Jorge <> wrote:
    > On Aug 31, 8:06 am, Steve Swift <> wrote:
    >
    >
    >
    > > Imagine I was writing the exact same webpage as a GUI application in its
    > > own right.  Every time a checkbox is clicked, the application has to
    > > update its datatabase. Imagine also that the application has the choice
    > > of handling this trivial update modally, or handling it asyncronously,
    > > re-enabling the interface whilst the update takes place (and possibly
    > > fails).

    >
    > > If I were in the newsgroup for the GUI builder, they would be telling me
    > > that I was nuts to do it asyncronously, opening up a nightmare of
    > > problems that might occur if the user started playing with the UI whilst
    > > the update was pending.

    >
    > Yes and no. It's not the same thing to disable a form's UI than to
    > have the app's UI (either a standalone GUI app or a browser) hanged.
    >
    > You can test it here :http://preview.tinyurl.com/5eu3ll
    >


    Hmmm, browsers keep changing... for the better : the UI is not frozen
    anymore (while the SYNC XHR takes place) in FF3s nor in Operas 9.5x.

    :)

    --
    Jorge.
     
    Jorge, Aug 31, 2008
    #15
  16. zalek

    Jorge Guest

    On Aug 31, 12:39 pm, "Richard Maher" <>
    wrote:
    >
    > OTOH, the Ajax abort/cancel doesn't appear to do much more than tidy up the
    > client and leave the server grinding?
    >


    Yes, but what else could it possibly do ?

    --
    Jorge.
     
    Jorge, Aug 31, 2008
    #16
  17. zalek

    zalek Guest

    On Aug 28, 11:05 pm, Jorge <> wrote:
    > On Aug 29, 3:55 am,zalek<> wrote:
    >
    > > I am writing application withAjaxin sync mode - xmlHttp.open("GET",
    > > url, false).
    > > I noticed that in FireFox handler doesn't starts. It starts when I use
    > > xmlHttp.open("GET", url,true).
    > > I need to use it in sync mode. Any ideas what can I do?

    >
    > The callback won't get called for synchronous XHR requests (there's no
    > need to).
    >
    > But (AFAIK) nothing prevents you from calling it ("by hand") if you
    > need to, inmediatly after the .open(,,false) :
    >
    > //xmlHttp.onreadystatechange= myCallback;
    > xmlHttp.open("GET", url, false);
    > myCallback();
    >
    > --Jorge.


    Guys,

    Thanks for all responses. First I want to clarify why I need sysc mode
    - I want to validate a form using Ajax. Yes - I know I can do this
    convetional way, but I want to learn Ajax too and for me it is a good
    oportunity.
    I made a specjal code for FireFox and called request handler "by hand"
    - but it did not work.

    For FireFox I coded:

    if (w_browser == "Firefox") {
    xmlHttp.open("Get", url, true);
    for(i=0;(i<9) || (xmlHttp.readyState == 4);i++){
    handleHttpResponse() ;
    }
    }

    function handleHttpResponse() {
    alert("HTTPResponse state: = " + xmlHttp.readyState + " i=" + i) ;
    [...]


    I never saw readyState == 4, but I know that few times the server
    defined on url was started. The problem is I need a message created by
    the server Ajax is using.

    Any ideas what to do?
     
    zalek, Aug 31, 2008
    #17
  18. zalek

    Jorge Guest

    On Aug 31, 2:11 pm, zalek <> wrote:
    > xmlHttp.open("Get", url, true);


    xmlHttp.open("Get", url, ** false **);

    >
    > Any ideas what to do?


    Are you running this in FF3 ?

    --
    Jorge.
     
    Jorge, Aug 31, 2008
    #18
  19. zalek

    Jorge Guest

    On Aug 31, 2:11 pm, zalek <> wrote:
    >
    > xmlHttp.open("Get", url, true);


    xmlHttp.open("GET", url, ** false **);

    > Any ideas what to do?


    If you're running this in FF3, see cljs thread # ce635b45f594fc64 "A
    bug in FF3's sync XHRs ?"

    --
    Jorge.
     
    Jorge, Aug 31, 2008
    #19
  20. Hi Jorge,

    > Yes, but what else could it possibly do ?


    With a context-devoid, connectionless, pile-of-pooh like HTTP, the options
    are clearly limited. (However that hasn't stopped people proposing
    "standards" such as long-polling, comet, and server-generated events.)

    If on the other hand you were to use a socket setup, similar to the example
    that I posted, then the server would be notified of socket disconnection and
    could take appropriate action to quiesce whatever it was doing. (There is
    also an example of a hot-abort button; so if a given query is taking too
    long, the clicking of the button will send an OOB character down the line.
    In this case the query can be cancelled, yet the connection maintained.)

    A copy of the Java Applet code is at: -
    http://manson.vistech.net/t3$examples/

    Regards Richard Maher

    "Jorge" <> wrote in message
    news:...
    On Aug 31, 12:39 pm, "Richard Maher" <>
    wrote:
    >
    > OTOH, the Ajax abort/cancel doesn't appear to do much more than tidy up

    the
    > client and leave the server grinding?
    >


    Yes, but what else could it possibly do ?

    --
    Jorge.
     
    Richard Maher, Sep 1, 2008
    #20
    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. Phi!
    Replies:
    1
    Views:
    189
  2. Trans
    Replies:
    2
    Views:
    495
    Trans
    Dec 12, 2005
  3. Luke Venediger
    Replies:
    3
    Views:
    158
  4. Replies:
    4
    Views:
    149
    Dr John Stockton
    Oct 17, 2005
  5. dlf
    Replies:
    5
    Views:
    137
    Evertjan.
    Jun 9, 2008
Loading...

Share This Page