My first thought was that it might be some code I had recently added to a JavaScript file which was responsible for capturing the name/value pair of the submit button pressed when you submit a form (which is the only way to get that information when using AJAX to submit form data). The code worked great in Firefox, but I hadn’t tested it yet for Internet Explorer at all, so I changed it around a bit to see if maybe some of that was causing it. My debugging progressed to completely commenting out that new code, essentially bringing me back to code I knew worked in Internet Explorer 7 before, but it was still crashing!

I started to dig a bit deeper and noticed that for some reason if I commented out one of my submit buttons (my form had two buttons with the same name – used to pick between two choices… both of which submit the form), it wouldn’t crash any more – but it wasn’t submitting the form via AJAX which it should have been, so there was still a problem somewhere. Since I was able to get a bit further now that Internet Explorer 7 wasn’t crashing, I was able to determine that it was choking somewhere in jQuery, at a piece of code that quite simply just tried to toUpperCase() a string – namely the method of the form (that is, whether it was to be submitted via GET or POST).

I played around a bit and noticed that if I hard coded in (to my JavaScript code that builds the form data to be sent via AJAX) a method of “post”, that it worked fine – it didn’t like it when I tried to retrieve the method set on the form however. After a bit more sleuthing, I decided to check up on the getAttribute() DOM function which I used to try and retrieve the form method. What I found was a piece of gold buried under the usual MSDN documentation; someone had posted a comment at the bottom mentioning an obscure bug when using getAttribute on forms… At first, I was a bit excited, hoping I had found the problem but I quickly saw that the bug was apparently just mentioning a problem when you used the name “id” on an input element which I was not doing in my code. However, I kept reading the description and noticed there was an additional bit of information stating that the problem was that the name property on an input element could actually override any key word in the DOM, potentially causing odd behaviour.

I quickly skimmed through my form, looking at the inputs and what name I had assigned them, but they were all fine, however the submit buttons were named “method” – which is a DOM property for forms! The comment quickly made sense and I knew I had found the problem; the submit button was causing a problem when I was trying to get the method property from the form through getAttribute()… it was clashing with the name property from the submit button because it’s name was set to “method” and this was causing Internet Explorer 7 to crash!

The fix was relatively simple – I just renamed my submit button to something other than “method” and presto, Internet Explorer 7 now worked just fine (and I was able to re-enable my second submit button without any problems too). Well, I shouldn’t say fine since I did discover another problem in that Internet Explorer 7 apparently submits the HTML code in between<button>…</button> tags instead of the value property defined on the button element, but that was a simple work-around thankfully.

Stupid Internet Explorer

After doing some initial debugging, it seemed that my responseText was coming back blank – but Firebug clearly showed that Firefox was getting the full DOM document back from the AJAX POST call, so I knew something was up with how the response was being handled by AJAX. Now, I use jQuery for the majority of my JavaScript code, so I was a bit surprised to find out that there was an AJAX problem since I figured that a bug like this would have likely at least already been reported. After a lot of searching on Google however, I only turned up one result that was quite similar to my problem which had no resolution. So it looked like I would have to solve this one entirely on my own.

I did more debugging, and out of pure luck I ended up noticing that the readyState on my XHR object was set to 0, which means that apparently an AJAX call hadn’t even been made yet. I found this rather odd to see a readyState of 0 since clearly an AJAX call had been made (and returned with success). I thought about the situation a bit and figured that perhaps I should move my debugging call (I was using console.log()) up the chain a bit so I did it as the first call from my AJAX completion callback function. After doing that I noticed that it was now correctly showing a readyState of 4. This meant that somewhere down the line, something was happening to my XHR object causing the readyState to be reset… and possibly resetting my entire XHR object!

Sure enough, I was indeed correct! The problem was that I was trying to directly access my XHR object from within a jQuery animation callback which obviously uses timers. Now, here is where I speculate because the problem only happens in Firefox, but I’m guessing that the XHR object was somehow being reset or altered after some time… very likely an internal browser cache system that was purging my XHR object. My solution was to simply copy the responseText to a variable before entering in to any timer based jQuery calls (essentially, I assigned the responseText to a variable as the first call from my completion callback function). Then, from within my jQuery animation callback I simply referred to the variable I created which had a copy of the responseText. No more random blank responseTexts!