There are many discussions like this on the internet, but I am confident I am now examining a very specific problem of Firefox, with a very specific AJAX routine.
Symptoms: there are other AJAX requests in the background, and there is a request initiated by the user, which requires confirmation (your average “are you sure you want to delete?” dialogue). The AJAX request to delete the entry never fired. Every AJAX request was in the default, asynchronous mode.
No matter what, I couldn’t for the life of me make that request work, everything else did. Only the “delete” functions didn’t (in Firefox, as Chome and Internet Explorer worked no problem).
I used console.log messages as crumbs along the way, to follow the flow, and it stopped right at onReadyStateChange, as anything after it wouldn’t show zip in the console. Which meant the onReadyStateChange wasn’t being triggered.
I even thought it was something off with the function name (maybe the delete inside it borked something, silly me thought).
I also tried switching to synchronous mode the incriminated requests… and welp, they worked! For a short while I thought about leaving them be synchronous, but I didn’t want those pesky warnings in the console about synchronous requests ruining the user esperience.
Only by chance an epifany happened, and the obvious came forth (I KNEW there had to be a reasonable explanation which I had yet to grasp).
Well, my configuration went like this (it’s an internal web application we are talking about): an AJAX request triggered each second to a PHP to check the user credentials and inactivity time, and an AJAX request by user intervention was launched to delete an entry… after a confirm dialogue requested, well, user confirmation for the delete (duh).
Everything worked flawlessly before, the problem started appearing after I added the background AJAX request each second (which I didn’t want to get rid of anyway).
As you may or may not know, the window.confirm dialogue is a synchronous structure, which means the page execution is frozen until the user presses either OK or CANCEL in the dialogue (same thing happens with the window.alert function).
So, imagine the background AJAX request being queued behind the confirm dialogue, and obviously taking precedence over anything else that had to come after, and the new AJAX request being formed right after the press on the OK button of the confirm dialogue, to delete the entry that the confirmation was for.
Well, these two requests were launched at the very same time, in a manner that Firefox (not the other browsers though) probably overlapped the onReadyStateChange and never triggered the one for the secondary AJAX request.
In fact getting rid of the confirmation dialogue solved the problem.
Either that, or I will have to come up with an asynchronous method of requesting user confirmation.