+1  A: 

There's a whole number of really good reasons IE does this, and I'm sure it's not something anyone would argue with - so the main objective is to get around it somehow to make things better for your users.

Sometimes its worth re-thinking how things are done. Perhaps disable the button, use javascript to check when all the fields are filled out, and fire off an ajax request once they are. If the ajax was successful, enable the button. This is but one suggestion, I'm sure there will be more...

Edit: more...

Do simple submission (non-AJAX), and if the checks fail, send a page back rather than an attachment. The page sent back could contain all the information originally submitted (plus whatever error message to the user) so the user doesn't need to fill out the entire form again. And I'm also sure there will be more ideas...

Edit: more...

I'm sure you've seen this type of thing before - and yes, it is an extra click (not ideal, but not hard).... an "if your download fails, click here" -> in this case, do it as you want to do it, but add a new link/button to the page when the AJAX returns, so if the download failed, they can submit the already validated form from a "direct user action". And I'm sure I'll think of more (or someone else will).....

Graza
Well I agree that IE does this for "good" reasons, but to a large extent those reasons involve other system software not being very smart. Note that Firefox and Safari and Chrome don't have this problem, and to my knowledge that's not considered a significant security exposure.
Pointy
+2  A: 

I take it you're submitting the form with a different target window; hence the form staying in place.

There are several options.

  1. Keep the submit button disabled and do ongoing validation in the background, polling the form for changes to fields and then firing off the validation request for a field as it changes. When the form is in a valid state, enable the button; when it isn't, disable the button. This isn't perfect, as there will tend to be a delay, but it may be good enough for whatever you're doing.
  2. Do basic validation that doesn't require round-trips to the server in a handler for the form's submit event, then submit the form and remove it (or possibly just hide it). If the further validation on the server detects a problem, it can return a page that uses JavaScript to tell the original window to re-display the form.
  3. Use a session cookie and a unique form ID (the current time from new Date().getTime() would do); when the form is submitted, disable its submit button but keep it visible until the response comes back. Make the response set a session cookie with that ID indicating success/failure. Have the window containing the form poll for the cookie every second or so and act on the result when it sees it. (I've never done this last one; not immediately seeing why it wouldn't work.)

I expect there are about a dozen other ways to skin this cat, but those are three that came to mind.

(Edit) If you're not submitting to a different target, you might want to go ahead and do that -- to a hidden iframe on the same page. That (possibly combined with the above or other answers) might help you get the user experience you're looking for.

T.J. Crowder
No, when you submit a form and the response is an attachment (that is, a file to download) the browser does not repaint the page.
Pointy
That last one looks like a really good idea! I wonder if the cookie would get set successfully if the download fails. Brilliant idea whether it works or not!
Graza
@Pointy: Ah, okay, it did seem a bit weird. I think these basic ideas could be adapted to what you're doing, but without being deep in the guts of it... @Graza: That's kind. I don't think I'd call it "brilliant" if it doesn't work, but thanks. :-)
T.J. Crowder
The cookie idea is truly awesome, now that I've allowed it to penetrate the stagnant fat layer around my head.The technique shall be called the Crowder Cookie Trick.
Pointy
@T.J. - I meant the idea was good. It's thinking outside the box, which you need to do a lot to get around the walls we hit in web development. Some ideas work, some don't - but just because they don't it doesn't mean they weren't good ideas
Graza
@Pointy: LOL! Cool, glad that worked. @Graza: Good point, and thanks again.
T.J. Crowder
Implemented and tested, works like a champ.
Pointy
Cool! ..................
T.J. Crowder