nerdscene.com

As I was testing a recent site I had designed in Internet Explorer for compatibility, I came across one of the forms which was apparently causing Internet Explorer 7 to crash. It put a real damper on the testing since it was causing a crash which I would consider to be pretty heavy on the “must fix” list before it goes live. The worst part was, I had done a lot of extensive testing with Firefox which showed no problems, and even Internet Explorer 8 was behaving as expected. Thankfully I have Internet Explorer 8 which finally has a decent set of developer tools built in, so I set forth to try and figure out what the problem was… hopefully!

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