3

I have a problem with IE (8, have not tested on 7). I have a very simple situation: I create a form element

var formNode = $('<form>');

I attach a bunch of other elements to the form (fieldsets with input elements inside of tables). I then attach the form to the DOM, and then bind a submit handler:

formNode.bind('submit', function (ev) { alert('submit of form!'); // do lots of stuff.... }

This works with Safari on my Mac (yah, I'm a Mac guy), and on Safari and Firefox on Windows, but the alert is never called when I click the submit button when using IE 8. Instead, the browser tries to submit a GET request for / (I have not set either a Method or an Action for the form - perhaps that is necessary?).

Any insights would be greatly appreciated as I am making changes hit-or-miss in order to debug.

Improve this question
6
  • "(I have not set either a Method or an Action for the form - perhaps that is necessary?)" Have you tried it? Commented Sep 24, 2010 at 14:08
  • Why have you bound the handler to the submit event of the form rather than the click event of the button? Commented Sep 24, 2010 at 14:18
  • What version of jQuery are you using? Commented Sep 24, 2010 at 21:15
  • I pull jQuery 1.4.2.min from Google's CDN. In isolation, I have simple code that generates a form and I attach a submit handler and all works fine. In the context of my app, which builds a lot into the DOM, the simple test case fails, so there is some interaction... I am trying to isolate... Commented Sep 24, 2010 at 21:38
  • Well, I found the problem, but not yet a cure. My app uses the (awesome) Sammy -- a Sinatra-like in-Browser evented router (code.quirkey.com/sammy). Sammy itself binds to all submit elements. So, my problem with IE must be an issue of the ordering of the bound event callbacks, which I am looking into. Commented Sep 25, 2010 at 17:42

3 Answers 3

Reset to default
2

There a variety of issues with listening for events from form elements with jQuery in Internet Explorer. There are a series of comments on the jQuery forum about: IE-specific issues with live ('submit'). Granted I know you are using bind and not live but many of the described problems involve attempts at using both.

I commented on your answer asking which version of jQuery you are using. If you haven't already and can do so I'd upgrade to the latest release.

A few code solutions:

Bind the submit handler to each child of the body element
adapted from synertech1 answer in the aforementioned jQuery forum discussion.

var submitHandler = function() { ... }; $("body").children().each(function() { $("form", this).bind("submit", submitHandler); })

Bind to the submit input type
I hate this option because the form element is the more appropriate element to bind to.

 $('form > input[type*="submit"]').bind('click', function(event) { var form = $(this).parent; form.submit(); event.preventDefault(); });
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Thanks for the link and suggestions. I am trying to narrow down the problem because what I have found is that if I build a minimal HTML file with a form and a submit button and bind to that, IE works. So I have spent hours now instantiating a form-and-button in my app, finding where it works... and where it doesn't, and am trying to hone in on a dividing line that may shed light on why it works in some cases and not others. I hope I am not fruitlessly spinning my wheels.
@Zhami In your tests what are you binding the event to, the button or the form? The suggestion to bind the submit handler to each child of the body element is there because there is conjecture that events bound form events at the document level have a propensity to be lost by IE. I'd bind them to the body and see what happens.
I am binding to the form itself. I'd like to get this to work that way, so will continue to investigate the "collision" (with the Sammy library) to see if I can find a focused work-around.
@Zhami binding to the body is still working from the form element but listening for the event on the body element. :)
1

You haven't said what level of HTML you're using, but FWIW, action is a required attribute on form elements in HTML4. So it wouldn't be too surprising if a browser behaved oddly without it. (In HTML5, the validator says it's not required any longer, probably because some of this stuff is now allowed on the submit buttons themselves.)

Improve this answer

5 Comments

HTML 4. I tried setting action="" on the element creation, and now the form doesn't even render on IE 8 (works on Mac Safari). Will keep trying...
action="" is also invalid. Try action="#". But if the form didn't even render, frankly I suspect there's a larger problem elsewhere.
Curious: if I try setting the action="#" in the jQuery element creation, the element is not created and the form doesn't render; code: formNode = $('<form action="#">') .... however if I set the action by .attr('action', '#') then the form renders. But still, the submit binding does not work.
I think we might need to see more code then. Certainly it's not reproduceable just with the code above (well, after the trivial missing ) is fixed).
My code that is having a problem executes in a context of a huge amount of other code. I am working to create a standalone test case. If I fail to achieve that, then I know the problem is with my context.
0

Are you remembering to return false (or event.preventDefault()) from your event handler? If not, the form will continue to submit, effectively navigating you to the action URL, or the same URL as the current document, if there is none. Though really there should be some action both for HTML validity and to provide a working non-JavaScript solution where possible (progressive enhancement and all that).

If you do have the return false, make sure no JavaScript errors are occurring in the handler code that abort the function before it gets to return false. Turn on JS error reporting in the Internet Options and/or use the debugger.

Improve this answer

1 Comment

I wish I had the problem of needing to stop propagation :-) But the problem is that the submit handler does not even execute. Yes, the code returns false. Right now for testing, I issue an alert on entry - which doesn't occur - and then return false. ... As for needing an action... my use-case is an in-browser Javascript app - there's nothing the server can do as all functionality for this form's action happens in the handler. This works for all Browsers I have tried except for IE. My app is not in any way "progressive" - if Javascript doesn't work, then the app is DOA.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.