Bug Tracker

Modify

Ticket #12233 (closed bug: fixed)

Opened 21 months ago

Last modified 18 months ago

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
Blocking: Blocked by:

Description

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

comment:1 Changed 21 months ago by gtr053@…

Also, this worked perfectly in jQuery 1.7.2.

comment:2 Changed 21 months ago by dmethvin

  • Cc jaubourg added
  • Priority changed from undecided to low
  • Status changed from new to open
  • Component changed from unfiled to ajax

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 21 months ago by dmethvin (previous) (diff)

comment:3 Changed 21 months ago by gtr053@…

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

comment:4 Changed 21 months ago by gtr053@…

Or an empty string

comment:5 Changed 20 months 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 20 months 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 20 months 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 20 months 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 20 months ago by jaubourg

  • Status changed from open to closed
  • Resolution set to fixed

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 20 months ago by jaubourg

  • Milestone changed from None to 1.8.1

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

comment:11 Changed 20 months 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 20 months 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 20 months 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 20 months 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 20 months 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 20 months ago by anonymous

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

comment:17 Changed 18 months ago by mikesherov

  • Keywords needsdocs removed

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.