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

[zalek]

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.

[Jorge]

On Aug 29, 3:55*am, zalek <[e-mail]:

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.

[GArlington]

On Aug 29, 2:55*am, zalek <[e-mail]:

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.

[optimistx]

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 ...?

[Steve Swift]

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]

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]

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/s...-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]

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.

[Gregor Kofler]

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

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)

[Jorge]

On Aug 29, 1:50*pm, Steve Swift <[e-mail]:

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]

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]

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" <St***********@gmail.comwrote in message
news:48******@news.greennet.net...

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]

On Aug 31, 8:06*am, Steve Swift <[e-mail]:

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

On Aug 31, 1:16*pm, Jorge <[e-mail]:

On Aug 31, 8:06*am, Steve Swift <[e-mail]:

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]

On Aug 31, 12:39*pm, "Richard Maher" <[e-mail]>
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.

[zalek]

On Aug 28, 11:05*pm, Jorge <[e-mail]:

On Aug 29, 3:55*am,zalek<[e-mail]:

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?

[Jorge]

On Aug 31, 2:11*pm, zalek <[e-mail]:

xmlHttp.open("Get", url, true);

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

>
Any ideas what to do?

Are you running this in FF3 ?

--
Jorge.

[Jorge]

On Aug 31, 2:11 pm, zalek <[e-mail]:

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

[Richard Maher]

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" <jo***@jorgechamorro.comwrote in message
news:df**********************************@f63g2000 hsf.googlegroups.com...
On Aug 31, 12:39 pm, "Richard Maher" <[e-mail]>
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]

On Sep 1, 2:03*am, "Richard Maher" <[e-mail]>
wrote:

>
With a context-devoid, *stateless* , pile-of-pooh like HTTP, the options
are clearly limited. (...)

Richard, the way I see it http has proved to be quite handsome (much
more than enough).
And lots of things can be done with it just needs a little bit more
verbosity than usual.

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/

But client-side Java... is it that stinky cold dying corpse ?
I'd rather wait for HTML5, and in the meantime will keep fudging with
http/XHRs.

:-)

Regards,
--
Jorge.

[Steve Swift]

Jorge wrote:

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.

True (and my work colleagues are complaining about a single-threaded
application that we we have to use that becomes unresponsive when doing
I/O to large files).

However, the page I was discussing has only one user, me, and since my
job is to keep the server running, having my entire browser hang when
something goes wrong is just about the *best* way to get my attention. :-)
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[GArlington]

On Aug 29, 12:33*pm, Steve Swift <[e-mail]:

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". :-)

It thould be perfectly all right with my thet of dentureth...
But, I guess you will not object if they offer you to watch a movie in
3-D glasses while the are working on your teeth...

>
--
Steve Swifthttp://www.swiftys.org.uk/swifty.htmlhttp://www.ringers.org.uk

[GArlington]

On Aug 29, 12:50*pm, Steve Swift <[e-mail]:

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.

How about you change the state on client side immediately, send
request to server to update DB, and notify the user if there are any
problems...

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 Swifthttp://www.swiftys.org.uk/swifty.htmlhttp://www.ringers.org.uk

[Michael Wojcik]

Richard Maher wrote:

With a context-devoid, connectionless, pile-of-pooh like HTTP, the options
are clearly limited.

HTTP is sessionless. It's not connectionless (at least not over TCP,
which is the only transport used in practice). And when the client
does its close or half-close, the HTTP server will get a FIN (modulo
network failure), just like any other TCP application.

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

Nothing in the sockets API makes that guarantee.

If it's a stream socket, over TCP, then if the client closes its end,
the client-side stack will try to send a FIN (or an RST, depending on
what kind of half-close the client does and other complications) to
the peer. That packet may or may not arrive. If it does, the
server-side stack will update its state, and report it to the server
in the appropriate manner. That's usually returning length 0 from a
receive operation, or returning the appropriate error indication from
a send operation.

could take appropriate action to quiesce whatever it was doing.

Not unless it checks, unless the server is using some mechanism (such
as Unix SIGIO) that lets the stack interrupt it. Also not part of the
sockets API, and completely outside the client's control.

What HTTP offers the client for aborting an operation on the server is
perfectly adequate for most purposes. Either the server pays attention
to the client's side of the connection, or it does not. Having the
client send an abort message on the HTTP request channel would add no
value; if the server's not checking that channel, it's not checking
that channel.

There are good reasons why HTTP does not use a separate control
channel (as eg FTP does). For one thing, it's a PITA for stateful
firewalls.

This is a slight simplification. There's no way for the server to
distinguish between a full, normal close by the client, and a client
half-close, except by trying to send data. In principle, a client
could send its request and then half-close the conversation, if it
doesn't want to send more data. However, RFC 2616 appears to encourage
servers to treat that as a full close:

-----
When a client or server wishes to time-out it SHOULD issue a graceful
close on the transport connection. Clients and servers SHOULD both
constantly watch for the other side of the transport close, and
respond to it as appropriate.
----- (8.1.4)

Since 2616 doesn't distinguish between half-close and full-close, it
appears that fully-compliant HTTP/1.1 servers have to detect a client
close of whatever sort (if possible) and terminate processing that
request.

That's already in the HTTP spec. There's no need to create another
protocol just to get that behavior, and as Jorge wrote, there's no
need for the client to do anything else. If the server is left
grinding, that's because the server isn't fully compliant with the
HTTP spec.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[zalek]

On Aug 31, 9:02*am, Jorge <[e-mail]:

On Aug 31, 2:11 pm, zalek <[e-mail]:

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.

Thanks Jorge for your help,

I solved my problem and now my Ajax code is working in sync mode in FF
and IE. Just in case someone else will have a similar problem, here is
my code:

function validate_user_info() {
try {
// Firefox, Opera 8.0+, Safari
w_browser = "Firefox" ;
xmlHttp=new XMLHttpRequest();
}
catch (e) {
// Internet Explorer
try {
xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
w_browser = "IE" ;
}
catch (e) {
try {
xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
w_browser = "not FireFox and not IE" ;
}
catch (e) {
alert("Your browser does not support AJAX!");
return ;
}
}
}

ajax_user_info();
return ;
}

function ajax_user_info() {
var url = "ajax_server.jsp?office=" +
document.forms[0].office.value +
"&car=" + document.forms[0].car.value ;

if (w_browser == "Firefox") {
xmlHttp.open("Get", url, false);
xmlHttp.onreadystatechange = handleHttpResponse;
}
else {
xmlHttp.open("Get", url, false);
xmlHttp.onreadystatechange = handleHttpResponse;
}
xmlHttp.send(null);
if (w_browser == "Firefox") {
i = 0;
while((i < 9) && (xmlHttp.readyState != 4) ) {
i++;
handleHttpResponse() ;
}
if (xmlHttp.readyState == 4) {
if (xmlHttp.status == 200){
var message = xmlHttp.responseText ;
alert (message) ;
}
}
}
return ;
}

function handleHttpResponse() {
if (xmlHttp.readyState == 4) {
if (xmlHttp.status == 200){
var message = xmlHttp.responseText ;
if (message.substr(0,2) != "ok") {
alert (message) ;
}

}
}
}
I am using code:
while((i < 9) && (xmlHttp.readyState != 4) ) {
i++;
handleHttpResponse() ;
}

in case Ajax server is slow, to gaine some time.

Zalek

[Hixie]

On Sep 18, 3:46*pm, "Richard Maher" <[e-mail]>
wrote:

>
So I once again beseech you - if you know or can influence anybody involved
in theHTML5WebSocket design team [...]

You yourself can influence the HTML5 work -- just join and post on the
WHATWG mailing list:

http://www.whatwg.org/mailing-list#specs

All feedback sent to that list is read and will in due course receive
a reply.

--
Ian Hickson

[Richard Maher]

Hi Ian,

[You yourself can influence the HTML5 work -- just join and post on the
WHATWG mailing list:]

I'll give it a go, and desperately hope that others will do the same.

Thanks for the Info.

Chhers Richard Maher

"Hixie" <ia*********@gmail.comwrote in message
news:94**********************************@i20g2000 prf.googlegroups.com...
On Sep 18, 3:46 pm, "Richard Maher" <[e-mail]>
wrote:

>
So I once again beseech you - if you know or can influence anybody

involved

in theHTML5WebSocket design team [...]

You yourself can influence the HTML5 work -- just join and post on the
WHATWG mailing list:

http://www.whatwg.org/mailing-list#specs

All feedback sent to that list is read and will in due course receive
a reply.

--
Ian Hickson

[efischer]

I agree with all you guys have said about how to write better code and
how to workaround the sync call problem. But the main point is that
this IS A BUG in FF3 and it should be fixed, it doesn't matter if it
is a good practice to use it or not.

This is in reality a very old bug from early FF1 versions that was
fixed as a side effect of some other fix in later FF1 versions. All
bugzillas about sync requests are still open since FF1, there was
never an explicit fix for it. Now in FF3 it came live again :(

-Ernesto

[Thomas 'PointedEars' Lahn]

ef******@ig.com.br wrote:

[...] But the main point is that this IS A BUG in FF3 and it should be
fixed, it doesn't matter if it is a good practice to use it or not.

What are you referring to?
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>