Side navigation
#10798 closed bug (fixed)
Opened November 15, 2011 09:01PM UTC
Closed November 16, 2011 02:09AM UTC
Last modified March 13, 2012 01:50PM UTC
live("submit") and .submit() would cause unobtrusive ajax live to fire twice
| Reported by: | michael.swain@dot.state.fl.us | Owned by: | dmethvin |
|---|---|---|---|
| Priority: | blocker | Milestone: | 1.7.1 |
| Component: | event | Version: | 1.7 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
I have code using jquery 1.7, MVC 3 unobtrusive ajax, jquery ui 1.8.5, and some custom dialog code. In my dialog code I convert a non-ajax form to an ajax form via adding the appropriate attributes for unobtrusive ajax to work with the form. in the button events for the dialog I call form.submit().
On the first load of the page the unobtrusive ajax live("submit") bidning would fire twice causing my form to be submitted twice.
I traced this issue to some code added (i presume in 1.7 sicne this issue started recently) for handling IE submit delegation. (lines 3605 - 3631 if the main js)
This code attaches a submit._submit handler which will fire a simulated submit. The problem seems to be that when I call .submit() the live handler is fired, then this simulate is fired, which in turn fires the live handler again.
I can work around the issue by removing the submit._submit event before i call .submit() which then prevents the simulated submit from firing.
example:
jQuery.event.remove(form[0], "submit._submit");
form.submit();
without the above code the live submtis twice, with the above it only submits once. This works for me because this form will only be submitted via code, but this may not be a practical work around for other uses. I think the issue is with the .submit() call, maybe it should have a wrapper that will disable the extra event since it is envoked manually anyway.
Attachments (0)
Change History (6)
Changed November 15, 2011 09:07PM UTC by comment:1
| component: | unfiled → event |
|---|---|
| milestone: | None → 1.7.1 |
| owner: | → dmethvin |
| priority: | undecided → blocker |
| status: | new → assigned |
Changed November 16, 2011 01:41AM UTC by comment:2
Can you put together a test case? The trigger only applies when a click or keypress happens on an element within the form, so I'm puzzled as to how it could be triggered by an automated form submit.
Changed November 16, 2011 02:07AM UTC by comment:3
I was able to create a failing test case but I am still not sure how this could happen on page load. It would be more likely to happen if the user had interacted with the form and then you submitted it via a programmatic submit. Is it possible that is what happened? I am going to assume it was since that was the case I could reproduce. Please do post back with some more information and see if the http://code.jquery.com/jquery-git.js version fixes the issue.
Changed November 16, 2011 02:09AM UTC by comment:4
| resolution: | → fixed |
|---|---|
| status: | assigned → closed |
Fix #10798. Don't re-bubble trigger()ed events in IE.
Since .trigger() already bubbles the event, we don't have to work around the non-bubbling IE events for that case.
Changeset: 80797f5805c335a818bda4237642fc4935bd77f6
Changed November 16, 2011 01:18PM UTC by comment:5
The form(s) I noticed it with were forms that you would interact with. They were being programmtically submitted because I was .load(ing) them into a dialog from ui, and firing .submit() from the dialog buttons. The forms do load with a submit button which I remove in the dialog, this is so the form can be used otuside of the dialog as well. I also use unobtrusive valdiation, so it could be a combo of events firing that caused this issue.
Changed November 16, 2011 03:44PM UTC by comment:6
I tested the git version and it did indeed resolve the issue. I look forward to the release of 1.7.1.
Yeah makes sense. I'll take a look, I think we just need to avoid firing the simulated submit if the event is trigger()ed.