Synchronous Ajax Requests

[aljoscha]

Hello everybody,

I am using Fork writing a thunderbird extension. I would have loved to
used prototype, but it doesn't play as well inside thunderbird :-(

There is a feature missing, though: synchronous ajax calls.
Those can be necessary, when one wants to make an ajax call reacting
on the dialogaccept event.
In order not to get an undefined request status (internally 13030;
basically the connection is lost with the dialog as it proceeds
closing, but the onFailure handler is still fired) the call needs to
be synchronous, so the dialog first finishes the call and then closes.

For more information see here:
http://groups.google.com/group/mozilla.dev.extensions/browse_thread/thread/4d13d0acc62dc7ff/c0b1c3df256ee135?lnk=st&q=XMLHttpRequest+on+close+of+dialog+never+finishes&rnum=1#c0b1c3df256ee135

The solution seems simple: Introduce an option sync and the n change
the following lines:

[...]
var async = !(this.options.sync || false);
this.request.open(this.method, url, async);
[...]
this.request.send(this.body);
if (!async) this.handleReadyState4();
}
...

I tested it and it works well.
What do you think?

Cheers,
Alex

[aljoscha]

[Peter Michaux]

Hi Alex,

> There is a feature missing, though: synchronous ajax calls.
> Those can be necessary, when one wants to make an ajax call reacting
> on the dialogaccept event.
> In order not to get an undefined request status (internally 13030;
> basically the connection is lost with the dialog as it proceeds
> closing, but the onFailure handler is still fired) the call needs to
> be synchronous, so the dialog first finishes the call and then closes.
>
> For more information see here:
> http://groups.google.com/group/mozilla.dev.extensions/browse_thread/thread/4d13d0acc62dc7ff/c0b1c3df256ee135?lnk=st&q=XMLHttpRequest+on+close+of+dialog+never+finishes&rnum=1#c0b1c3df256ee135

It looks like in the third email at that link the sync solution is
said not to work. Your experience is different?

It still could be a good feature for Fork, however.

> The solution seems simple: Introduce an option sync and the n change
> the following lines:
>
> [...]
> var async = !(this.options.sync || false);

How about just this

var async = !!!this.options.sync;

> this.request.open(this.method, url, async);
> [...]
> this.request.send(this.body);
> if (!async) this.handleReadyState4();
> }

Seems like a reasonable addition.

Peter

[aljoscha]

> > There is a feature missing, though: synchronous ajax calls.
> > Those can be necessary, when one wants to make an ajax call reacting
> > on the dialogaccept event.
> > In order not to get an undefined request status (internally 13030;
> > basically the connection is lost with the dialog as it proceeds
> > closing, but the onFailure handler is still fired) the call needs to
> > be synchronous, so the dialog first finishes the call and then closes.
>
> > For more information see here:

> >http://groups.google.com/group/mozilla.dev.extensions/browse_thread/t...

>
> It looks like in the third email at that link the sync solution is
> said not to work. Your experience is different?

Yes, using a synchronous request works perfectly.

> It still could be a good feature for Fork, however.
>
> > The solution seems simple: Introduce an option sync and the n change
> > the following lines:
>
> > [...]
> > var async = !(this.options.sync || false);
>
> How about just this
>
> var async = !!!this.options.sync;

Yeah.

[Peter Michaux]

On 8/23/07, aljoscha <aljo...@weisshuhn.de> wrote:

[Re: change to ajax.js for sync requests]

var async = !!!this.options.sync;

this.request.open(this.method, url, async);
[...]
this.request.send(this.body);
if (!async) this.handleReadyState4();

I just tried this in Mac/Firefox and the callback fires twice. Have
you seen this effect with a sync request and your code suggestion?

Thanks,
Peter