Bug Tracker

Opened 7 years ago

Closed 7 years ago

#12417 closed bug (invalid)

Serialize multi-select limit

Reported by: scott.barnsley@… Owned by: scott.barnsley@…
Priority: undecided Milestone: None
Component: unfiled Version: 1.8.0
Keywords: Cc:
Blocked by: Blocking:

Description

Hi,

I seem to have encountered a limitation in the ".serialize()" function...

For one large form (which I am processing via custom ajax form processing), I am unable to pass all of the selected values in a multi-select because in some cases, there are over 2000 options populated via ajax (appending the option elements).

Via debugging I have been able to check the number of multi-select values which were serialized in the string, which seems to hit a maximum of 1165.

I have no idea why this would occur, but it seems to be happening across all the browsers I have available to test at the moment (Chrome/Chromium, Firefox, LuaKit and IE).

This may be unrelated to jQuery and if so, I would appreciate the heads-up.

Thanks, Scott.

Change History (4)

comment:1 Changed 7 years ago by anonymous

Please note, the data was being passed to a "$.post" function, so GET or URL string length limits should not be a factor.

comment:2 Changed 7 years ago by dmethvin

Owner: set to scott.barnsley@…
Status: newpending

Can you provide a test case? It sounds like you could paste your long select into jsfiddle.net and call serialize on it.

This may be unrelated to jQuery

Since this is the jQuery bug tracker it would be good to limit tickets to ones that are related to jQuery. If you click submit on a plain web form that has 2000 entries does it work? It seems very odd that different browsers would have the same limits.

comment:3 Changed 7 years ago by scott.barnsley@…

Status: pendingnew

Thanks for the quick reply.

I ran a few more tests, including using jsFiddle and have found the problem.

We were using a fairly long name for the field, "customer_outlets[]", which didn't work (http://jsfiddle.net/dZfVH/2/) but changing the name to something shorter, such as "cust_o", did work (http://jsfiddle.net/dZfVH/1/).

We see this to be a problem for 2 reasons:

  1. We having naming standards we follow for all views in out web applications.
  2. Once we have more outlets, are we going to encounter this issue again even with a smaller field name (http://jsfiddle.net/dZfVH/4/)?

Thanks, Scott.

comment:4 Changed 7 years ago by dmethvin

Resolution: invalid
Status: newclosed

I'm pretty sure this has nothing to do with jQuery. You can see that serialize works fine if you alert out the lengths:

http://jsfiddle.net/dZfVH/5/

However, I have seen data truncation over the wire before, when developing an application that needed to send back large chunks of data via POST requests. Be sure your server is configured to handle large requests, I remember the old ASP.NET servers sometimes would reject posts over 100kb if not configured right. There was also one UK ISP that had some sort of problem with its network that would truncate post data silently when it got big. This was about four years ago so I don't recall all the details.

Our solution was to switch to JSON format and normalize the data because it had a lot of redundant values. That turned out to be easier on bandwidth and not a problem because the normalized data matched the backend SQL tables.

Anyway, good luck.

Note: See TracTickets for help on using tickets.