This is a question for a forum, not the bug tracker. Please ask there.

Replying to [comment:1 dmethvin]:

This is a question for a forum, not the bug tracker. Please ask there.

I have the same problem with 1.9.0 and I think it's a bug as it lets IE crash. Got the problem in combination with jquery.validate and jquery.chosen (http://harvesthq.github.com/chosen/).

Solution:

Chnage the begin from JQuery.parseJSON(data) function from

// Attempt to parse using the native JSON parser first
if ( window.JSON && window.JSON.parse ) {
	return window.JSON.parse( data );
}

if (data === null) {
        return data;
}

into

if (!data || data === null) {
        return null;
}

// Attempt to parse using the native JSON parser first
if ( window.JSON && window.JSON.parse ) {
	return window.JSON.parse( data );
}

to handle the case the data argument is undefined.

It looks like we have created a situation here where we silently allow invalid JSON of undefined or null if there is no JSON.parse. But it's not valid JSON nonetheless. The API docs say it takes a string. I'm more inclined to remove the check altogether here, but reopening for discussion.

Maybe you are true, the problem can be somewhere else. But how should an empty string be handled? If it is permitted, why not null. Actually the call stack showed me that JSON.parse has been called from inside an error handler. And in my opinion, throwing an error from inside an error handler / catch block is the last what a developer and maybe a user is expecting.

I think our original goal was for jQuery.parseJSON() to do the same things as the browser's JSON.parse() method. This is what JSON.parse() does:

> JSON.parse(undefined)
  SyntaxError: Unexpected token u
> JSON.parse("")
  SyntaxError: Unexpected end of input
> JSON.parse(null)
  null
> JSON.parse(false)
  false
> JSON.parse(NaN)
  SyntaxError: Unexpected token N

The check for data === null returns null for a null input, just like JSON.parse(). Since the method is documented to receive a string, the other cases aren't in the domain of valid inputs in any case.

In other words, we're debating situations that aren't supposed to arise. Stop sending garbage to the method and it will stop complaining. If you call jQuery.parseJSON(x) and are unsure whether x is defined but want a null, use jQuery.parseJSON(x || null) instead. As a reader of the code I would prefer to see that in order to understand that x may not be defined.

BUT

It appears vmonfrie may have jumped the ticket with an unrelated complaint in any case. The original report says the problem is that **JSON is undefined** in IE9 emulating IE7, which it is and our code accounts for that.

So we need a test case in jsFiddle.net that doesn't include other code and shows the problem. It sounds to me like some plugin is browser sniffing and possibly doing an incorrect shim of the JSON object, but we would need a test case.

No matter what the intention was behind the parseJSON method, the documentation (currently) clearly states "Additionally if you pass in nothing, an empty string, null, or undefined, 'null' will be returned from parseJSON." Only afterwards it says "Where the browser provides a native implementation of JSON.parse, jQuery uses it to parse the string." Therefore you would expect 'null' as the result for any of the 'borderline' cases and not an exception. Anything else would be a breach in the code contract and in my opinion is a bug in 1.9.0.

https://github.com/jquery/api.jquery.com/issues/243

#13430 is a duplicate of this ticket.

#13412 is a duplicate of this ticket.

#14384 is a duplicate of this ticket.