number of requests send to server in FireFox

I'm having 6 forms each one in IFrame in same page domain , on-click on button save & close the forms should be submitted and then the page should closed , but i noticed that the first 5 forms are submitted but the last one is delayed for while, and the page closed before it complete saving it .that happened just at FireFox , I test it over IE and Chrome and it works good.

Here is some of the code:

<div id="div_1">
<iframe id='iframe_1'  name='iframe_1' width="100%" frameBorder='0' 
    src='/aaa.jsp'></iframe>
</div>

<div id="div_2">
<iframe id='iframe_2'  name='iframe_2' width="100%"开发者_运维百科 frameBorder='0' 
    src='/bbb.jsp'></iframe>
</div>

 !-- ... --


<div id="div_6">
    <iframe id='iframe_6'  name='iframe_6' width="100%" frameBorder='0' 
        src='/hhh.jsp'></iframe>
</div>

save & close button :

<input type="button" value="Save & Close" 
       onclick="for(var i = 0; i < frames.length; i++) { frames[i]._Submit('Update');}time_to_close();" />

<script>
function time_to_close()
   {

   setTimeout(function(){
        window.close();
    }, 5000);
   }

</script>

any one can help ?

All browsers implement a limit on the number of concurrent connections to the same server. (Some servers do as well.) The actual number varies depending on browser vendor and HTTP version, but is typically somewhere between 2 and 8. There's a round-up of the state of things as of a couple of years ago (which is probably still fairly accurate) on this page; quoting a relevant bit:

Browser         HTTP/1.1    HTTP/1.0
IE 6,7            2            4
IE 8              6            6
Firefox 2         2            8
Firefox 3         6            6
Safari 3,4        4            4
Chrome 1,2        6            ?
Chrome 3          4            4
Opera 9.63        4            4
Opera 10.00alpha  4            4

Your time_to_close function assumes that all of the submits, together, won't take longer than five seconds. That assumption is incorrect even absent concurrent connection limits. A user's connection can temporarily be saturated, there can be a temporary routing problem that eventually gets sorted out, the server can be overloaded and queuing connections, etc., etc., etc. You're better off having the submit return something you can check in the frames (a flag, whatever), and then setting up a timed check waiting for the flags to all be set (with an appropriate timeout, of course, possibly giving the user the option of waiting longer).

Better yet, though, if you're in control of the server end you could collect all of the data together into one submission, which would almost certainly improve perceived performance markedly (the overhead of setting up the HTTP connection to send the form is frequently the longest part of a form submission, barring the server processing the form itself slowly).