This content has been marked as final. Show 14 replies
you're using getURL() to open the "popup" and that popup opens a html page that embeds a swf that contains a loadClip statement?
And just to give a little more info, we have been able to reproduce this problem in IE 6 and 7 with Flash players 8 and 9 (we haven't tested Flash 7 as it is below our version limit). The swfs are published in Flash 8.
I believe this is at least in part related to the browser limits for the number of simultaneous connections permitted to the same domain. I think, from memory, IE limits this to 2 but other browsers may permit up to 4 for example. There optimal solution is probably to host your assets at another domain.
I had an example recently where two flvs and a flash clip were all requested from the same domain inside the same page, which blocked the html navigation until the download queue freed up one of the two slots. It would I believe under these circumstances have the same effect on a getURL navigation request to the same domain. I found a way to cancel the MovieClipLoader download which solved the problem:
I don't if its necessary to do this part, but I kept a reference to the original MovieClipLoader (e.g. mcl)...and called mcl.unloadClip(target_mc); (which you said you had tried)
Then... I used it to attempt to load a non-existent movie into the same target:
Your problem sounds kind of similar. It might be worth trying this approach.
Oh.. ok, well your issue might be a little different then, but some of the symptoms are the same.
A couple of other questions...
Is your loading swf (what you call the "flash course" ) a large file with a long timeline or is it just a small container swf which is supposed to load all the other parts? If its a large file that is still downloading... then that would count as one of the download slots for that domain in IE. If it just requested one other download (e.g. on frame 1) then that would be using both of them.
If you want to be sure to eliminate this as the cause... then you could try this:
(for diagnostic purposes only - I realise its not a solution).
BTW I found that physically closing the window prevented the moviecliploader downloads that were in progress from completing as well (which is good, because you would expect it to ).
The symptoms do sound similar. The theory in this case would be that when the window is closed by the user hitting the browsers X button, Flash/IE never release the download slots appropriately. It seems as if IE is "stuck" because both the IE window and the Flash instance that made the intial media request are gone (closed) and there is nothing left to communicate with.
Another interesting result is that after this problem has occurred - the very next request that launches a popup window from the "flash menu" (whether that be an HTML page or another "flash course") produces a 404 error if you wait long enough. The IE status bar on this new popup window does not do anything (no green bars indicating its communicating with the server). It's as if it never even attempts to make the request to the server and simply waits for the client IE browser (itself) to timeout.
You make a good point about the download slots although we believe that the first (.swf) file is completely down before we make the media requests. We will extract this code from the larger framework and set up some "demonstration" files. We will wait to ensure that the initial .swf is completely down before it makes a media request so that we are only using 1 download slot. If we can't reproduce the error using only 1 download slot we will then make 2 media requests and see if we can reproduce the error when both download slots are used and the browser is closed.
We are hoping to provide a link later.
We're using "getURL" because we need to format the new HTML window that's opening (i.e., set its size, remove the browser controls, etc.).
But even if we do away with the flash menu and use simple HTML hyperlinks , the problem still persists.
i can't duplicate that issue.
i have main.html that embeds main.swf and main.swf contains two buttons (btn, btn1) and the code:
p.s. i tested in firefox 126.96.36.199 and ie 7.0.5730.11
The test you did is basically what we're attempting to do. I've posted a link of our test site here:
This does a very similar thing to your code. The menu.htm document has 2 hyperlinks in it. The top link ("Test 1") opens a popup window that contains a cliploader.swf movie. This clip has three links in it (upper right) that you can click on to start downloading 1, 2 or 3 asset SWFs via the MovieClipLoader class. If you close this window before the download(s) complete, the problem eventually occurs (i.e., server communication with the domain fails).
The hard part here is that the issue seems to be, at least in part, timing/performance related. You may need to try this several times before you see the problem (and using a program like NetLimiter to slow the downloads can help). We've had better luck reproducing the error on lower/speed and higher latency connections.
If you download all 3 SWFs during each test, eventually you'll use up the browsers maximum connection slots. Raising that limit from 2 (as GWD has pointed out) will delay the problem, but eventually you still run out of open slots and the server communication dies.
If you use the second menu hyperlink ("Test 2") and try the same test, the MovieClipLoader aborts successfully and the problem doesn't seem to occur. In the case of this link, the cliploader.swf movie is moved to an "unload" frame (which terminates the clip loaders), and an alert box pops up to ensure that the movie has sufficient time to complete its clean up.
So, this takes care of half of the problem. The trickier issue has to do with closing the popup window before the graphics actually begin downloading. If you start one of the downloads, then wait until you see the "start" indicators (beneath the download links) before closing, the unloading/clean-up code fails to rectify the problem and eventually IE stalls. On some occassions we have been able to produce the error in just a couple of attempts. But it can calso take 15 or more "launch & close" sessions before the problem occurs. This might seem somewhat trivial, but in the real site we're using, users may open multiple popup windows over the course of their browsing session, during which hundreds of media assets will be downloaded. So there is a reasonable chance they will encounter the problem.
The source code for our little demo can be downloaded from here:
Thanks for your time.
As a quick update, it does appear that this problem is less likely to occur on high speed/low latency connections.
Also, I have been able to produce the same bug using the standard "loadMovie" method instead of a clip loader, so it's not a problem that's specific to the one class.
The demo site has been updated with more directions, as well as an update to the source code to allow up to 3 simultaneous downloads to help increase the chances of the problem occuring.
Thanks again to everyone that has spent time looking into this.
If its related to the number of simultaneous downloads from the same domain, then the simplest (or perhaps the most complicated in other ways - you need to consider crossdomain permissions etc) fix is to host your media/swf files at another dedicated domain for media. A number of larger sites do this to optimise site performance but also to avoid this type problem (I'm pretty sure I read something about that a couple of months back when I had to deal with the problem I described earlier).
Did anyone get a solution to this? I'm surrently having the exact same problem with the loadclip calls