I’m having a really irritating problem doing something that I’m sure I’ve done before. The setup is this:
- There’s a form which is submitted via a “click” handler on a button, though the submit is ultimately a simple call to the form’s native
submit()function. - The form’s target is an iframe, which is initially filled with an empty page (that is, its source object is an URL for an empty page). That is, the “target” attribute of the form is the same identifier (and yes, it’s a valid identifier) as the “name” and “id” attributes of the iframe (and yes, it’s unique)
Now the goal of this setup is as follows: the form contains file upload fields. Should something be wrong with one of the files uploaded, the server will report back an error. If the error response (that is, the html page with a new copy of the form, along with appropriate error messages) were to be allowed to reload the original window, then the file input fields would be cleared. That’s not good.
Thus the form submits to the iframe, so that the response from the server can be a small page that knows it’s in that hidden iframe, and knows to move the error messages up to the form.
One more thing: the form itself is also in an iframe, as part of a popup modal dialog (like a jQuery UI dialog, only slightly different; same idea though).
The setup works fine – on the first submit. In other words, if I supply nice happy files to upload, the server ships back the successful response, and the dialog is closed correctly. If I send a bogus file, the server responds with an error page that correctly copies its stuff up to the form page.
On the second submit, however (like, if I fix the bogus file input field), the browser insists on sending the server response to a new browser tab. As far as I can tell, the form’s “target” remains correct, the iframe “name” and “id” attributes aren’t changed, and I even make sure to update the hidden iframe “window.name” and “window.id” values. None of that is helping; I always get a new browser tab.
I’m trying to set up a slightly simpler test case to see if I can rule out some of my framework code (the stuff that does the submit), though via a few console.log() calls I think that stuff is OK; it’s certainly OK on all the other dialogs etc. in the site. When/if I create a simpler version I’ll post it. In the meantime, if any of you insanely smart people recognize this situation and know of a trick to make it work, I’d be really thankful.
I see the same behavior in both Firefox (3.6) and Chrome, so it’s got to be my problem and not a browser quirk (well, at least that’s what I think to be true).
Well somehow my secondary “target” iframe seems to be losing it’s “name” attribute, though I don’t know how or when that happens. The
<iframe>element itself still has the correct name, but the “window” object inside does not – even though code is trying to set it.I am able to hack around the weirdness for now by having that “submit” code check for a targetted form, find the target iframe, and then make sure that its contentWindow has a “name” value that matches the “name” attribute on the iframe. How/why I have to do that, I don’t know, and I’m sure it’s due to something else I’m doing wrong.