#13169 closed bug (notabug)
'JSON' is undefined error when calling jQuery.parseJSON
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | ajax | Version: | git |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
With Jquery 1.9.0 and also jquery-1.8.0.min.js: A call of the method 'jQuery.parseJSON' causes: "SCRIPT5009: 'JSON' is undefined jquery-1.8.0.min.js, line 2 character 16953"
in I.E. 7 (I use I.E.9 with IE7 as 'document version').
Change History (11)
comment:1 follow-up: 2 Changed 10 years ago by
Resolution: | → notabug |
---|---|
Status: | new → closed |
comment:2 Changed 10 years ago by
Replying to 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.
comment:3 follow-up: 4 Changed 10 years ago by
Resolution: | notabug |
---|---|
Status: | closed → reopened |
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.
comment:4 Changed 10 years ago by
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.
comment:5 Changed 10 years ago by
Owner: | set to [email protected]… |
---|---|
Status: | reopened → pending |
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.
comment:6 Changed 10 years ago by
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.
comment:7 Changed 10 years ago by
Resolution: | → notabug |
---|---|
Status: | pending → closed |
comment:10 Changed 9 years ago by
Component: | unfiled → ajax |
---|
This is a question for a forum, not the bug tracker. Please ask there.