jQuery, JSON and IE – Getting Incorrect Array Length

October 14, 2008

Has anyone had the following problem? When loading a JSON array (through something like $.getJSON), Internet Explorer will sometimes report the length of the array being one higher than other browsers, with the extra element in the array being blank.

I don’t know if this is a problem in other libraries, but I suspect it is. But I do know that it’s happened to me when using jQuery’s Ajax functions.

Why is this occurring?

I was tormenting myself with this same question on a client project, and discovered that although a bit of browser quirkiness was involved, it was actually an error on my part.

I hate it when it’s me. ;)

As it turns out, I had an extra trailing comma at the end of the last element in my array. For example, in the following array:

{“gamesImDroolingFor”:[{"developer":"Blizzard","title:"Diablo III"},{"developer":"Square Enix","title":"Final Fantasy XIII"},]}

You’ll notice that there’s a comma after the last game’s bracket (which has been turned red for emphasis).

Firefox will ignore that comma, since clearly there’s no new object after it. Internet Explorer, the special child of the web, isn’t quite so bright, so it adds an extra, blank element to the array it creates.

Go IE.

The solution is easy, of course. Remove the unneeded comma.

I hope this helps prevent other developers from driving themselves batty trying to figure out what’s going wrong with their own arrays.

Respond To This Post

Share This Post With Others: |

Category: javascript | Tags: , , , ,

6 Responses to “jQuery, JSON and IE – Getting Incorrect Array Length”

  1. First, I am by no means a fan of Internet Explorer — I use Firefox as my browser in linux, and I’m a web developer and all versions of IE to date are the bane of my career. However, this is one of those rare cases where IE is actually interpreting the RFC for JSON (RFC4627) correctly. Granted, the RFC does not explicitly say that the trailing comma “MUST NOT” exist, or “SHOULD NOT” exist, the grammar used to describe the comma-separated lists clearly shows that a value should come after the value-separator:

    > object = begin-object [ member *( value-separator member ) ] end-object

    > array = begin-array [ value *( value-separator value ) ] end-array

    So this is actually Firefox being generous and allowing value-separator to *not* be followed by a value, which is sort of going against the RFC. For a PHP developer, having a trailing comma with no value following it is allowed, and many developers add it by default in order to prevent parse errors that occur when you add a new element to the list and forget the comma. But one must admit it’s non-standard and unneeded, so strict interpretation should require that a value follows a value-separator.

  2. @Joe – Well… that’s a good point. I’ll admit, I’m so accustomed to IE interpreting something the wrong way that I often jump to conclusions and assume a behavioral difference between Internet Explorer and any other browser means that IE is behaving incorrectly.

    Score a point for IE. And actually, it’s probably lazy programming to include that trailing comma, so I can’t really call IE to task for being strict about it.

  3. Rock it. That was exactly my issue. thanks!!!

  4. [slap my forehead] Of course! Thanks for this article.

    And no matter if IE is right in doing this way, I’m still mad at it for giving me useless debug informations.

    “is null or not an object” WTH?!?

  5. @Charles – I completely agree that IE’s debug information is probably the most useless in the world. It drives me batty.

  6. Thanks, bud. I could foresee this fix being a big pain in the a$$ – toth for keeping your post up.