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

[zalek]

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

Thanks,

Zalek.

[Jorge]

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

On Aug 29, 3:55 am, zalek <zalekbl...@hot mail.comwrote:

I am writing application with Ajax in sync mode - xmlHttp.open("G ET",
url, false).
I noticed that in FireFox handler doesn't starts. It starts when I use
xmlHttp.open("G ET", 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.onready statechange= myCallback;
xmlHttp.open("G ET", url, false);
myCallback();

--Jorge.

[GArlington]

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

On Aug 29, 2:55 am, zalek <zalekbl...@hot mail.comwrote:

I am writing application with Ajax in sync mode - xmlHttp.open("G ET",
url, false).
I noticed that in FireFox handler doesn't starts. It starts when I use
xmlHttp.open("G ET", 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.

[optimistx]

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

zalek wrote:

I am writing application with Ajax in sync mode - xmlHttp.open("G ET",
url, false).
I noticed that in FireFox handler doesn't starts. It starts when I use
xmlHttp.open("G ET", 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 ...?

[Steve Swift]

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

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]

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

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

[optimistx]

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

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.

[Richard Cornford]

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

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("G ET", 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.

[Gregor Kofler]

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

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

[Evertjan.]

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

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

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.dropO ff(D);
while (holes in one)
nextSibling.dro pOff(D);

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Jorge]

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

On Aug 29, 1:50 pm, Steve Swift <Steve.J.Sw...@ gmail.comwrote:

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.

[Steve Swift]

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

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]

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

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" <Steve.J.Swift@ gmail.comwrote in message
news:48bb812e@n ews.greennet.ne t...

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

[Jorge]

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

On Aug 31, 8:06 am, Steve Swift <Steve.J.Sw...@ gmail.comwrote:

>
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]

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

On Aug 31, 1:16 pm, Jorge <jo...@jorgecha morro.comwrote:

On Aug 31, 8:06 am, Steve Swift <Steve.J.Sw...@ gmail.comwrote:
>
>
>

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.