-
Notifications
You must be signed in to change notification settings - Fork 20.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
serialize() ignores input elements of type submit #2321
Comments
The documentation says:
This is a dup of trac-1138 and before that, trac-3523. The latter was discussed in in 2008. Those are discoverable via Google. |
Ok, so that's by wrong design. http://www.w3.org/TR/html401/interact/forms.html#h-17.13.2
|
From http://bugs.jquery.com/ticket/11138
Wrong: it is if a button press triggered the submit event.
You shouldn't have to. |
The documentation says what the method does. The tickets explain the reasoning. There is no submit button activated when you call |
I got it: it is documented. Sorry for missing that. Yet the behavior is wrong.
which is wrong
Unless you call it from a listener that has been triggered by pressing the button.
Backward compatibility is an argument, indeed. It is to be considered whether to fix the behavior and break BC or keep a wrong, inconsistent behavior for the sake of BC. I've seen BC broken in the past in jQuery in favour of improved consistency. Also, it's not that easy to incur in a case where the change would actually do harm, though of course it is possible.
Indeed, you could be penalizing people who read the documentation and worked around the incorrect (but documented) behavior. But see above. |
How would jQuery know that, as opposed to being called some other way? Can you show some code? |
@teo1978, omg, there is no reason to be aggressive... @dmethvin, |
Aggressive? I frankly don't think I'm the one who's been aggressive |
I may be missing something but couldn't document.activeElement be used inside .seriazize()? Doesn't your example demonstrate that it would work? |
activeElement is the current DOM element who has actually the focus. So... when jQuery is serializing the form, I suppose we can't have the guaranty the focus is still on the submit button :/ |
If it wasn't, then your example above wouldn't work either, would it? |
Hmm yep but I use activeElem just after the |
Of course. The only question is whether using activeElement is reliable and cross-browser. That's worth investigating and this issue should be reopened (also if that turns our not to work for all cases I'm pretty sure there are other ways to be explored, as this issue had always been dismissed as non existing) Also, according to the definition of successful given in the standard, when there's only one submit button, it should always be included (unless there's some caveat about that), and that seems trivial. |
I mean whether three are cases in which the submit button triggering the event triggering serialize may not be the active element for some reason |
That's an extremely common occurrence. Forms are frequently submitted via other form controls. See http://jsbin.com/xutubediya/1 |
That's not an occurrence of what I'm talking about at all. If you're sending the form via other form controls, then either: Actually, there seems to be a discrepancy between the definition of succesful in the standard cited above and browser behavior (at least Chrome). Chrome (when sending the form without any javascript) sends the first submit input element if you send the form by hitting Enter. If that's the correct behavior (in which case the definition in the standard is either unclear or I'm missing something), then again, having serialize() behave the same is trivial, because it's just a matter of finding the first submit element (when none is the activeElement) |
Actually, it is. You said:
And since it's impossible to know that we're "inside a submit event", you suggested we use |
I meant a submit event triggered by clicking on a submit button. For implicit submission, see my last comment. |
Mmm, no, sorry, that alone isn't enough to distinguish whether or not we're inside a submit event.
Aren't you a bit too fast in declaring it's IMPOSSIBLE? |
The value of This is a huge amount of magic to apply just to get a value just for some cases. So instead of having a simple note in the docs saying "we don't add this, add it yourself", we have a big list of conditions where we will fail to do it because of browser issues. I don't see it being worth the inconsistency, especially because people don't read the existing docs and making them more complicated won't help things. If you're looking for a simple workaround, put a hidden input in the form with the name/value pair you want to send with the submit button, and don't give the submit button a name so it won't be successful if submitted by the user without JavaScript. |
Ok, so what about the other solution?
.
No, I wasn't. I was hoping for a better jQuery where one wouldn't need any workaround at all in order to have a form guaranteed to be serialized always exactly the same way as it would be if sent by the browser. But I do understand that the lack of that is mostly JavaScript's fault itself, which apparently doesn't provide you a method to obtain that, obliging you (i.e. jQuery) to write from scratch the code that does the serialization, having to mimic what the browser itself would do. |
http://jsbin.com/folonusapu/1/edit?html,js,output
Expected output:
Observed output:
serialize() should serialize the EXACT SAME DATA that would be sent by the browser if the form was sent normally. That includes input elements of type "submit", but jquery ignores them.
I can't believe I'm reporting this bug in 2015.
The text was updated successfully, but these errors were encountered: