Script works only with firebug installed, or in non-mozilla

[RossRGK]

A script I've implemented is doing this annoying thing where it works in
mozilla only if you have Firebug installed.

I was all excited to find someone had solved what sounded like the same
problem, as outlined in <a href =
"http://lukav.com/wordpress/2007/04/12/firefox-firebug-and-synchronos-calls-problem/#comment-750">this
article</a> but unfortunately, it turns out that I am not using sync
XMR.open, but rather async.

ALSO, the related bug: <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=383304">383304</a>
sez that the bug was fixed in FF 3.0.1

I am running FF3.0.1 in MacOS 10.4.11 (though I had also seen it on
win32 platform earlier this year, and put off fixing it till now).

I'm not 100% sure that it was related to the XMR calls, but my big
concern is that Firebug makes my code work, and it also works in Safari,
but not in any mozilla-derived browsers, which sounds like the bug
above. So the signature is the same. Nothing worse than a debugger
that makes stuff work only in its presence!

Is anyone aware of any other situations where Firebug makes something
work in Mozilla, other than this XHR.open sync bug?

I guess I'm going to jump in and try to figure out where my code fails,
but doing it without a debugger in my browser is going to be a real pain...

Thx- Ross.

 

[RossRGK]

Some debugging and I found that I am getting an xmlhttp.readyState that
is not ready yet.

From the W3C example, which my script follows quite closely, we call a
routine upon the onreadystatechange event.

xmlhttp.onreadystatechange=state_Change;
xmlhttp.open("POST","mypage",true);

So my problem is that with Firebug loaded, state_Change gets called when
the .readyState is only at 1 or "loading" state. It needs to traverse
through the "loaded", "interactive" states to get to 4="complete".

In non-Mozilla browsers, this doesn't seem to be an issue, and in
mozilla+firebug it always arrives with state = 4.

Sounds like mozilla is too responsive, and only when loaded down with
firebug does it behave like the non-mozilla browsers?

Does anyone have an insight into what is happening? Does
onreadystatechange fire every time the state traverses from 0 to 1 to 2
to 3 to 4?

If so, perhaps the other firings are not queued as it goes from 1
through to 4 while the first state=1 firing is being processed, since I
don't see a 4-state occur.

Should I use a while loop to wait for the state to change to a 4? Will
it change to a 4 or is another 'event' needed to make that happen

Any help appreciated...

Ross.

 

[David Mark]

Some debugging and I found that I am getting an xmlhttp.readyState that
is not ready yet.

 From the W3C example, which my script follows quite closely, we call a
routine upon the onreadystatechange event.

   xmlhttp.onreadystatechange=state_Change;
   xmlhttp.open("POST","mypage",true);

So my problem is that with Firebug loaded, state_Change gets called when
the .readyState is only at 1 or "loading" state.  It needs to traverse
through the "loaded", "interactive" states to get to 4="complete".

I can't imagine what Firebug has to do with that.

In non-Mozilla browsers, this doesn't seem to be an issue, and in
mozilla+firebug it always arrives with state = 4.
Huh?


Sounds like mozilla is too responsive, and only when loaded down with
firebug does it behave like the non-mozilla browsers?

Sounds like you are unfamiliar with the readystatechange event.

Does anyone have an insight into what is happening? Does
onreadystatechange fire every time the state traverses from 0 to 1 to 2
to 3 to 4?

It fires when the readyState property changes. It will not go through
all of the states in every case (e.g. local files, cached data.)

If so, perhaps the other firings are not queued as it goes from 1
through to 4 while the first state=1 firing is being processed, since I
don't see a 4-state occur.

Should I use a while loop to wait for the state to change to a 4?  Will
No.

it change to a 4 or is another 'event' needed to make that happen

No other event is needed.

 

[Jorge]

Some debugging and I found that I am getting an xmlhttp.readyState that
is not ready yet.
(...)
Does anyone have an insight into what is happening? Does
onreadystatechange fire every time the state traverses from 0 to 1 to 2
to 3 to 4?

Yes it should.

If so, perhaps the other firings are not queued as it goes from 1
through to 4 while the first state=1 firing is being processed, since I
don't see a 4-state occur.

Should I use a while loop to wait for the state to change to a 4?  Will
it change to a 4 or is another 'event' needed to make that happen

No loops, no, just put this into the first line of
the .onreadystatechange callback function:

if (xmlhttp.readyState !== 4) { return; }

 

[RossRGK]

I can't imagine what Firebug has to do with that.


Sounds like you are unfamiliar with the readystatechange event.

Duh - Thanks for the insight.

 

[RossRGK]

Yes it should.


No loops, no, just put this into the first line of
the .onreadystatechange callback function:

if (xmlhttp.readyState !== 4) { return; }

Thanks for that, Jorge, and for clarifying that onreadystatechange does
fire for each state change. That was constructive and helpful.

It helped clarify that behaviour and thus I discovered what my problem
was (posted here for anyone else that runs into this...)

Turns out that I was also using a write to the firebug console with
console.log("Message") statements. It turns out that mozilla based
browsers (e.g. firefox & camino) will stop processing the javascript at
that point and bail-out, whereas non-mozilla (e.g. safari) will ignore
it and keep going. So when I got the first state msg, and the console
write was seen, processing stopped and I couldn't see the other states
come thru'.

With firebug installed, of course, FF interprets and writes the message
to the console.

I've put any console messages I wanted inside a test for my debugging
mode and now all browsers are behaving the same way.

Thanks again for a helpful reply!

Cheers,
Ross.

 

[David Mark]

Thanks for that, Jorge, and for clarifying that onreadystatechange does
fire for each state change. That was constructive and helpful.

Please do not quote other people's signatures. Also, read what you
quote. You got this exact advice in the previous post. It would have
been just as helpful had you read it.