Bug Tracker

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#12233 closed bug (fixed)

jQuery.post() raises "RangeError: Maximum call stack size exceeded"

Reported by: gtr053@… Owned by:
Priority: low Milestone: 1.8.1
Component: ajax Version: 1.8.0
Keywords: Cc: jaubourg
Blocked by: Blocking:


Specifying the url, data, and dataType parameter without specifying the success parameter (which is of course optional) raises "RangeError: Maximum call stack size exceeded" in Chrome 21.0.1180.77 beta. A similar error occurs in Firefox 14.0.1. Both were tested on Mac OS X 10.8. Here is a "working" example: http://jsfiddle.net/TAVKB/

Change History (17)

comment:1 Changed 11 years ago by gtr053@…

Also, this worked perfectly in jQuery 1.7.2.

comment:2 Changed 11 years ago by dmethvin

Cc: jaubourg added
Component: unfiledajax
Priority: undecidedlow
Status: newopen

It didn't work perfectly in 1.7.2, it was ignoring the dataType parameter which it thought was a (bad) success callback. The consequences are just worse in 1.8. Here's the documented signature:

jQuery.post( url [, data] [, success(data, textStatus, jqXHR)] [, dataType] )

That says the data, success and dataType arguments are optional and independent of each other. However, there are some ambiguities; what if you wanted to specify a dataType but no data or success callback? Both are strings so there's no way to know which one you mean.

If you just add a null for the callback it works fine:

jQuery.post('/echo/text/', 'test=test', null, 'text');

Given the docs and the consequences, I'm inclined to fix this by trying to improve the parameter hockey we play. But really, if you're doing tricky stuff you're much better off making it explicit by adding the null or better, using $.ajax rather than the shortcut methods.

Alternatively, we can just document the success argument as manditory (if you want to provide dataType).

jQuery.post( url [, data] [, success(data, textStatus, jqXHR) [, dataType] ] )
Last edited 11 years ago by dmethvin (previous) (diff)

comment:3 Changed 11 years ago by gtr053@…

Shouldn't data always have an equal sign in it? See what I'm getting at?

comment:4 Changed 11 years ago by gtr053@…

Or an empty string

comment:5 Changed 11 years ago by jaubourg

We should probably look into handling parameters better, but something is fishy in the Callbacks implementation, it shouldn't go "berserk" like it does.

comment:6 Changed 11 years ago by robert@…

I'm actually getting the same thing, but using $.ajax. Not sure what the best path from here is.

async: true
cache: true
dataType: "script"
success: "x.y.handleResponse"
url: "http://localhost&callback=x.y.handleResponse"
__proto__: Object

Like others, it worked fine in 1.7.x

comment:7 Changed 11 years ago by gtr053@…

This problem occurs when jQuery interprets success as a string. Robert, this is likely where your problem is coming from. Your problem is not a bug in jQuery.

comment:8 Changed 11 years ago by anonymous

Yup. You're correct. Strangely, I actually had a check from the 1.6 days in there like this:

if (this.callback != 'string')

all I had to do was update to:

if (typeof this.callback != 'string'){

Anyway, now working for me. Would be nice if this failed more gracefully however, Chrome handles this better than Firefox which becomes unresponsive in at least some cases.

comment:9 Changed 11 years ago by jaubourg

Resolution: fixed
Status: openclosed

Makes sure "adding" a string to a Callbacks object doesn't cause a stack overflow, just ignore the value like 1.7.x righfully did. Fixes #12233. Unit tests added.

Changeset: 9d07525a71e7bc12f606d8015d21425c5580e262

comment:10 Changed 11 years ago by jaubourg

Milestone: None1.8.1

Now, do we also fix "the parameter hockey we play" or do we document?

comment:11 Changed 11 years ago by dmethvin

I think we should document that the callback must be there, even if it's just a null placeholder. That way the string following it is always the dataType and can't be mistaken for the data arg. Does that seem reasonable? If so add a needsdocs.

comment:12 Changed 11 years ago by jaubourg

Keywords: needsdocs added

Seems reasonable enough to me... put null in place of the callback if you wanna provide a dataType.

comment:13 Changed 11 years ago by gtr053@…

IMHO, it's hard to get them mixed up. As I was saying earlier, the data parameter, when a string, can either be empty or have an equal sign in it? Neither of which dataType should be. I can't imagine it being much more difficult than normal "parameter hockey". Requiring one optional argument present in order for another optional argument to be allowed is silly IMO. If we are going down the use null as a placeholder road, what would happen if the data parameter is omitted? We'd be back at square one.

comment:14 Changed 11 years ago by anonymous

I'll offer a note here: overloading methods in JavaScript is inadvisable. Not trying to flame-bait, but the simple facts are that the resolving the behavior based on so-called "parameter hockey" incurs runtime overhead, is hard to reason about, and often results in flaky, brittle code. IMO, overloading should be kept to an absolute minimum, and I'll offer a rule-of-thumb for situations like these: if you can't simply look at the number of arguments, or use a simple, reliable type-check of some sort to resolve the proper behavior, don't overload the method.

comment:15 Changed 11 years ago by dmethvin

@anonymous, totally agreed. That's why I'm not inclined to "fix" this any further in code. The current messy signature of jQuery.post() is what it is, however; there's no way to fix it retroactively without causing even more pain. Unless you happen to have a time machine.

comment:16 Changed 11 years ago by anonymous

@dmethvin - deprecate the signature but leave the implementation as-is for legacy reasons?

comment:17 Changed 11 years ago by mikesherov

Keywords: needsdocs removed
Note: See TracTickets for help on using tickets.