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

[Jorge]

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

On Aug 31, 12:39 pm, "Richard Maher" <maher...@hotsp amnotmail.com>
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]

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

On Aug 28, 11:05 pm, Jorge <jo...@jorgecha morro.comwrote:

On Aug 29, 3:55 am,zalek<zalekb l...@hotmail.co mwrote:
>

I am writing application withAjaxin 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.

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("G et", url, true);
for(i=0;(i<9) || (xmlHttp.readyS tate == 4);i++){
handleHttpRespo nse() ;
}
}

function handleHttpRespo nse() {
alert("HTTPResp onse state: = " + xmlHttp.readySt ate + " 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]

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

On Aug 31, 2:11 pm, zalek <zalekbl...@hot mail.comwrote:

xmlHttp.open("G et", url, true);

xmlHttp.open("G et", url, ** false **);

>
Any ideas what to do?

Are you running this in FF3 ?

--
Jorge.

[Jorge]

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

On Aug 31, 2:11 pm, zalek <zalekbl...@hot mail.comwrote:

>
xmlHttp.open("G et", url, true);

xmlHttp.open("G ET", url, ** false **);

Any ideas what to do?

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

--
Jorge.

[Richard Maher]

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

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" <jorge@jorgecha morro.comwrote in message
news:df9c3d10-3d60-4fe7-ab8a-f86354b387e1@f6 3g2000hsf.googl egroups.com...
On Aug 31, 12:39 pm, "Richard Maher" <maher...@hotsp amnotmail.com>
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]

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

On Sep 1, 2:03 am, "Richard Maher" <maher...@hotsp amnotmail.com>
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]

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

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]

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

On Aug 29, 12:33 pm, Steve Swift <Steve.J.Sw...@ gmail.comwrote:

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]

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

On Aug 29, 12: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.

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]

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

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]

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

On Aug 31, 9:02 am, Jorge <jo...@jorgecha morro.comwrote:

On Aug 31, 2:11 pm, zalek <zalekbl...@hot mail.comwrote:
>
>
>

xmlHttp.open("G et", url, true);

>
xmlHttp.open("G ET", url, ** false **);
>

Any ideas what to do?

>
If you're running this in FF3, see cljs thread # ce635b45f594fc6 4 "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_i nfo() {
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.XMLHT TP");
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.js p?office=" +
document.forms[0].office.value +
"&car=" + document.forms[0].car.value ;

if (w_browser == "Firefox") {
xmlHttp.open("G et", url, false);
xmlHttp.onready statechange = handleHttpRespo nse;
}
else {
xmlHttp.open("G et", url, false);
xmlHttp.onready statechange = handleHttpRespo nse;
}
xmlHttp.send(nu ll);
if (w_browser == "Firefox") {
i = 0;
while((i < 9) && (xmlHttp.readyS tate != 4) ) {
i++;
handleHttpRespo nse() ;
}
if (xmlHttp.readyS tate == 4) {
if (xmlHttp.status == 200){
var message = xmlHttp.respons eText ;
alert (message) ;
}
}
}
return ;
}

function handleHttpRespo nse() {
if (xmlHttp.readyS tate == 4) {
if (xmlHttp.status == 200){
var message = xmlHttp.respons eText ;
if (message.substr (0,2) != "ok") {
alert (message) ;
}

}
}
}


I am using code:
while((i < 9) && (xmlHttp.readyS tate != 4) ) {
i++;
handleHttpRespo nse() ;
}

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

Zalek

[Hixie]

Re: More Socket support (Re: Ajax in sync mode works with IE, doesnot work with Firefox)

On Sep 18, 3:46 pm, "Richard Maher" <maher...@hotsp amnotmail.com>
wrote:

>
So I once again beseech you - if you know or can influence anybody involved
in theHTML5WebSock et 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]

Re: More Socket support (Re: Ajax in sync mode works with IE, does not work with Firefox)

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" <ian.hickson@gm ail.comwrote in message
news:94f90f43-efef-46df-b85e-f7d6c22c2fc2@i2 0g2000prf.googl egroups.com...
On Sep 18, 3:46 pm, "Richard Maher" <maher...@hotsp amnotmail.com>
wrote:

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

involved

in theHTML5WebSock et 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@ig.com.br]

Re: More Socket support (Re: Ajax in sync mode works with IE, doesnot work with Firefox)

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]

Re: More Socket support

efischer@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, <f806at$ail$1$8 300dec7@news.de mon.co.uk>