In IE, form with remote and confirm are submitted even when the user cancels

[raroni]

As far as I can see, the current jquery-driver assumes that the form submit event is not fired if the input[type=submit]'s click event handler returns false.

In IE, this is not the case. This example illustrates it:

<form id="formx" action="flaf">
  <input id="submitx" type="submit">
</form>

<script type="text/javascript">
  $('form input[type=submit]').live('click', function(e) {
    alert('submit clicked!');
    return false;
  });

  $('form').live('submit', function() {
    alert('this is called for IE, not for Chrome/Firefox!');
  })
</script>

To make things even worse, IE is actually not submitting the form after calling the submit event handlers.

The result of this behavior is that forms with data-remote and data-confirm are always submitted in IE, even if the user clicks cancel in the confirm() dialog.

For instance, this will generate such a form.

<%= button_to 'text', 'path', :remote => true, :method => :put, :confirm => 'Sure?' %>

[raroni]

By the way, in my app I temporarily fixed this problem by setting the data-confirm on the form element instead of the submit button. Not pretty, but it works.

[mislav]

In your first comment you weren't clear that it's the button that has the "data-confirm" attribute, not the form element itself. Your second comment clears this up.

I didn't know that button_to puts the "data-confirm" attribute on the button rather than form. If there's only one submit button, I always add the attribute to the form itself, so I never spotted this.

Which IE versions are affected? Any ideas how to fix?

[raroni]

It was my understanding that Rails always put "data-confirm" on the submit button, and therefore I did not mention that. Sorry 'bout that :)

I confirmed this behavior in IE 7 and 8. Canceling a form's submit event from the submit button's click event (by calling return false in jQuery) seem to be impossible with IE 7/8.

The most elegant solution I think, would be to make Rails' button_to put the "data-confirm" on the form element instead of the button element.

It could also be solved by letting allowAction() search for any submit buttons with a "data-confirm" if does not find any on the form it self. If we do this, we should of course remove the allowAction() from the buttons click event handler.

Let me know what you think about the two ideas.

[mislav]

I haven't still used these features in Rails 3 so I don't know what they generate. I use prototype-ujs and jquery-ujs mostly in Sinatra, Rails 2 apps, and some Rails 3 apps where I write attributes by hand because that's how I do it in the first two frameworks :)

I wouldn't change this in Rails. They're not doing anything wrong. It's our job to support this. I would like an elegant solution in code that's not a special workaround for IE, but changes how we process this stuff so we avoid such issues. I don't have time right now, so feel free to take a stab at this at your own time

[raroni]

Haven't got the time to come up with something right now either. I will bookmark this and get back to it sometime.

[JangoSteve]

I was able to track this down. As Rasmus pointed out, the problem is that after the click event of the submit input is cancelled, the form's submit event still get's triggered in IE.

This is caused by jQuery, which manually triggers the form's submit if one of it's submit inputs or images are clicked for browsers that don't support propagation of the submit event (you guessed it, IE). You can see this implementation in jQuery here.

Normally, the click event would get cancelled by a javascript confirm box. However, since we live-bind to the button's click event, and jQuery directly binds this submit-triggering behavior, it gets called before rails.js ever cancels the event.

Anyway, I was able to fix this behavior in IE without breaking any of the tests (whoopie!), by calling e.stopImmediatePropagation() (see docs).

EDIT: See this pull request for the fix.

[raroni]

Great job! Thanks Steve :)