Flash: Lost submovie requests - new to Mozilla 1.1

VERIFIED FIXED in mozilla1.2beta

Status

()

Core
Plug-ins
P3
normal
VERIFIED FIXED
16 years ago
11 years ago

People

(Reporter: Jonathan Phillips, Assigned: serge (gone))

Tracking

Trunk
mozilla1.2beta
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:NA])

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
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.

Comment 1

16 years ago
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?

Comment 2

16 years ago
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

Comment 3

16 years ago
I heard back from the reporter, the working Mozilla Build ID is 2002053012
(Reporter)

Comment 4

16 years ago
Created attachment 97814 [details]
first half of log during run with lost requests

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

Comment 5

16 years ago
Created attachment 97815 [details]
second half (probably has needed info)

lost requests end in /servlet/flash/ins.swf
(Assignee)

Comment 6

16 years ago
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.
(Assignee)

Comment 7

16 years ago
taking this bug for further investigation
Assignee: beppe → serge

Updated

16 years ago
Priority: -- → P3
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.2beta
(Assignee)

Comment 8

16 years ago
this is the regression from fix for bug 106253

Comment 9

16 years ago
Why does adding to load groups cause this problem?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 10

16 years ago
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:(

Comment 11

16 years ago
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

Comment 12

16 years ago
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.
(Reporter)

Comment 13

16 years ago
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

(Assignee)

Comment 14

16 years ago
*** Bug 167322 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 15

16 years ago
*** Bug 165942 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

16 years ago
Created attachment 101346 [details] [diff] [review]
patch v1

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

Comment 17

16 years ago
Comment on attachment 101346 [details] [diff] [review]
patch v1

r=peterl
Attachment #101346 - Flags: review+
(Assignee)

Comment 18

16 years ago
Darin, could you sr= here please?

Comment 19

16 years ago
serge: please address comment #12 first.  thx!
(Assignee)

Comment 20

16 years ago
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 21

16 years ago
Comment on attachment 101346 [details] [diff] [review]
patch v1

ok, sounds good. sr=darin
Attachment #101346 - Flags: superreview+
(Assignee)

Comment 22

16 years ago
Checked in nsPluginHostImpl.cpp;
new revision: 1.444; previous revision: 1.443

Thanks all.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Assignee)

Comment 23

16 years ago
for verification see test cases from duped bug 167322, bug 165942

Comment 24

16 years ago
thx, serge. verifi with dup'ed testcases taht this is fixd.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.