Question

I have a class which enables forms with a file-type input to be submitted via AJAX. It creates a hidden IFRAME element, changes the form target property so that it submits to the IFRAME, submits the form, then changes the target back to what it was. It also adds an onLoad event to the IFRAME so I can get a callback. The onLoad function also removes the IFRAME from the page before firing my callback function.

The class works perfectly, I get the callback as expected. In Firebug’s Net panel, I see the request, I see the response, all is well. But, as soon as the submit starts, the browser tab for the page changes to “Connecting” with the loading spinner and never changes back. It makes the tab appear to be loading, this will go on for days if I leave the browser open.

The question, then, is: Is there any way for me to stop this manually, or is there some other way that I can prevent it from starting?

Here are the Response Headers as taken from the Net panel:

Date    Fri, 02 Sep 2011 15:23:15 GMT
Server  Apache/2.2.10 (Win32) PHP/5.3.1
X-Powered-By    PHP/5.3.1
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control   no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma  no-cache
Set-Cookie  PHPSESSID=agncdnha86mtci7dmuvriobak2; path=/
Content-Length  165
Keep-Alive  timeout=5, max=100
Connection  Keep-Alive
Content-Type    text/html

And a capture of the Net panel below. The POST is from the submission of the form, the GET is caused by the callback function, it is changing the source of an image on the page.

This is not specific to this page, it happens anywhere I use this technique to submit a file/image via an IFRAME. This affects my current version of Firefox (6.0), but also affected previous versions (5.x, 4.x, 3.x). The fact that the IFRAME is removed from the page after it loads makes this especially baffling – even if the request never finished, the removal of the element should effectively kill/stop and “connecting” that the browser thinks is happening.

UPDATE
Per the answer from @Sidnicious, I added a timeout to the callback function to introduce a delay in removal of the IFRAME element. I experimented with the length of the delay, even a 1ms delay is adequate. This certainly qualifies as a work-around, but I’d still like to know if anyone can shed some light on to the why of it, preferably leading to an avoidance of using the timeout all together. I’ve included the modified code (with the timeout) below, in case it is helpful. This is the onLoad event for the IFRAME (io us a reference to the frame element):

        var obj={};
        var success = true;
        try{
            obj.responseText = io.contentWindow.document.body?io.contentWindow.document.body.innerHTML:null;
            obj.responseXML = io.contentWindow.document.XMLDocument?io.contentWindow.document.XMLDocument:io.contentWindow.document;
        }
        catch(e){ success = false; }
        if( success ){
            this.fireEvent('onSuccess', obj.responseText );
        }else{
            this.fireEvent('onFailure', obj );
        }
        this.fireEvent('onComplete', obj );
        io.removeEvent('load', uploadCallback );
        setTimeout(function () { // <--- this timeout prevents the issue
            io.dispose();
        }, 1);

Answer 1

Update: the Firefox bug is now marked as “fixed” and will make it into a near-future update.

---

I’ve run into this too and would love to see the root cause fixed.

• I talked to a couple of Firefox developers (mbrubeck and gavin), and they think that it’s a bug! The same issue was reported, and fixed, in 2005 for Firefox 1.9. Then, bug 489259 was opened in 2009. mbrubeck has graciously moved it out of the “unconfirmed” pile.

• Safari behaves better than Firefox, but an error message (“One error in opening the page…”) shows up in the status bar if you remove the iframe during the load event. I found two similar WebKit bugs which have been open since 2007: 15485 and 13281.

This appears to happen when you remove an iframe from the document during the load event. JavaScript events fire synchronously — that is, in series with the browser’s own handling of the web page. That’s why it’s possible to prevent a form from being submitted or prevent a keypress or mouse click from being registered from within an event handler.

The last time this bug was fixed in Firefox, the cause was that the removing an iframe from the page makes it forget which page owned it, but the iframe notifies the page that it was finished loading after the load event.

Anything you schedule with setTimeout happens after the current cycle of the event loop — after the browser finishes what it’s doing right now. So, using setTimeout to remove the iframe, even with a timeout of zero, lets it finish:

iframe.onload = function(){
    // Do work with the content of the iframe…

    setTimeout(function(){
        iframe.parentNode.removeChild(iframe);
    }, 0);
}

You can find this technique in use in the jQuery form plugin.