User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020904 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/2002090408 Unfortunatly I can not provide a url for you to use. However, I will work with you to solve this bug. I work on a complex flash interface that continually loads submovies. The interface works fine with the Mozilla 1.0 release but looses requests in 1.1. Sometimes requests appear not to make it to our server. Sometimes they make it to the server but don't make it back to the mozilla client. The best way I can describe it is communication gets clogged between the flash movie and our server. The key question is: What has changed between 1.0 and 1.1 that would effect flash to server communication. This bug appears in flash 4, 5, and 6 as well as on linux and windows. Reproducible: Always Steps to Reproduce: 1. Please contact me and I will provide a link to our product. 2. 3. Actual Results: Requests were lost/ignored. Expected Results: Allowed communication to continue normally.

Jonathan: can you give us teh build date for the app that does work, that will help us narrow down what changes went in. Also, what server environment are you using?

I forgot to ask this: can you please enter the following into your autoexec.bat or your environment dialog. Exit from the application, open the app and perform the task, then shut down the app. Please attach the log file to the bug so we can see what is going on. Thanks SET NSPR_LOG_MODULES=Plugin:5,PluginNPN:5,PluginNPP:5,nsHTTP:5 SET NSPR_LOG_FILE= *** *** point to a text file, for example: C:\WINDOWS\DESKTOP\pluginlog.txt

I heard back from the reporter, the working Mozilla Build ID is 2002053012

lost requests end in /servlet/flash/ins.swf?... most likely find them in second half

lost requests end in /servlet/flash/ins.swf

hmm, by some reason connection channel got an error request's status for /servlet/flash/ins.swf?no=2 nsHttpChannel::OnStartRequest [this=21c8380 request=227585c status=804b0002] Jonathan, could you email to me the url i can use as a test case? thanks.

taking this bug for further investigation

this is the regression from fix for bug 106253

Why does adding to load groups cause this problem?

because on NPN_GetURL with target != 0 we are sending OnLinkClickEvent than we'll get: nsHttpChannel::Cancel(nsHttpChannel * const 0x0423b570, unsigned int 2152398850) nsLoadGroup::Cancel(nsLoadGroup * const 0x04b3f328, unsigned int 2152398850) nsDocLoaderImpl::Stop(nsDocLoaderImpl * const 0x04b3f0b0) line 336 nsURILoader::Stop(nsURILoader * const 0x0158ec68, nsISupports * 0x04b3f0c8) nsDocShell::Stop(nsDocShell * const 0x04b12a70, unsigned int 1) line 2650 nsDocShell::InternalLoad(nsDocShell * const 0x04b12a60, nsIURI * 0x04b3e640, nsDocShell::InternalLoad(nsDocShell * const 0x04b12a60, nsIURI * 0x04b3e640, nsWebShell::OnLinkClickSync(nsWebShell * const 0x04b12ba4, nsIContent * OnLinkClickEvent::HandleEvent() line 469 HandlePLEvent(OnLinkClickEvent * 0x040936d8) line 483 PL_HandleEvent(PLEvent * 0x040936d8) line 643 + 10 bytes ... we cancel all network activities for load groups, which is right when users click on the link on the page, but it's wrong in our case:(

Perhaps plugins shouldn't be added to load groups then? Or maybe a special flag not to cancel the stream? Real also doesn't like when the stream is canceled: http://bugscape.mcom.com/show_bug.cgi?id=14295

you do not need to have a plugin's channel in the load group _if_ you have some other nsIRequest impl added to the load group that can respond to Cancel properly. that is, you can't just let the plugin keep on chugging along after the user has advanced to another webpage. (but, i would assume plugins have some other way of knowing when the page containing a plugin is going away.) imagelib for example does not add the network channels to a load group. instead it adds a "proxy" nsIRequest object that corresponds to the channel. it does this because several image loads may correspond to the same network channel, and it doesn't want the canceling of one image load to disturb the loading of some other image load (perhaps living in some other webpage) that references the exact same URL. so, it can be done, but you have to be very careful to ensure that the network channel does get canceled eventually / at the right time.

fyi - the macintosh flash player continues to run movies after its owner page has been unloaded when the owner page is contained in a frameset. This eventually leads to a memory fault. Considering the existance of this ongoing bug I would be carefull about trusting flash to clean up properly. for what it's worth

*** Bug 167322 has been marked as a duplicate of this bug. ***

*** Bug 165942 has been marked as a duplicate of this bug. ***

In this patch I removed internal plugin's channel created by |NPN_Get[Post]URL| calls from the load group. Please review.

Comment on attachment 101346 [details] [diff] [review] patch v1 r=peterl

Darin, could you sr= here please?

serge: please address comment #12 first. thx!

darin: this patch is a temp solution for 1.2 release, there is a bug 117766 fixing which should touch this issue also, probably we'll implement something alike imagelib's proxy. And you are right all plugins channels are canceled from |nsPluginStreamListenerPeer::OnDataAvailable| if plugin instance is gone (page was deleted) by returning error form here http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp&rev=1.443&root=/cvsroot#2292

Comment on attachment 101346 [details] [diff] [review] patch v1 ok, sounds good. sr=darin

Checked in nsPluginHostImpl.cpp; new revision: 1.444; previous revision: 1.443 Thanks all.

for verification see test cases from duped bug 167322, bug 165942

thx, serge. verifi with dup'ed testcases taht this is fixd.

This caused bug 369503.