122475 - [viewpoint] Mozilla continues to download streams that the plugin cancels

Status: RESOLVED WORKSFORME

(Plugins Graveyard :: Viewpoint Media Player, defect)

Description

[Ari Berger]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    0.9.4. branch

I am seeing 2 separate issues that I think are results of this same bug:
Our plugin has its own private cache.  If we need a url, we check our cache to 
see if we have the file, and find its date and size.
We then ask the server for the file using GetURLNotify.  On NPP_NewStream, we 
check that the date and file of the stream match the info. we have in our 
cache.  If it is, we cancel the stream: we return NPERR_FILE_NOT_FOUND and read 
the file out of our own cache.  Everything works great- the browser no longer 
passes us anything else from that stream.
However, when I use a network sniffer, I see that even though you are not 
giving us any more of the file, you continue to download the whole file.
This is a serious performance hit on certain types of our content, because it 
really ties up bandwidth.

The second time where I think that we see the behavior is this:
We have begun dialup testing of our plugin.  And QA has noticed (I have yet to 
confirm) that if you try to close the page or the browser while we are in the 
middle of downloading a large file, the browser sort of hangs for a bit- it 
won't close until the file is downloaded.
I will see if I can confirm this tomorrow, but it sounds to me not too 
different from the first problem, so it is kind of likely.


Reproducible: Always
Steps to Reproduce:
1.Install Viewpoint plugin (http://cole.viewpoint.com/~aberger/readme.txt)
2.View any Viewpoint content:
eg http://cole.viewpoint.com/~ddavies/lego
3.Allow the content to stream in. Leave the page.  We should now have it cached.
4. Go back to the page.  You should see us requesting the files from the 
server, but canceling the streams (returning errors) in NPP_NewStream. 
5. If you use a download meter, you should see that you download the same 
number of bytes in both cases.

Perhaps it would be easier to see on content with larger files- if you need 
another test case, let me know.

Comment 1

[Peter Lubczynski]

copy/paste from e-mail:

I'm not quite sure why it's doing this. We should probably close the stream for
performance reasons. Looking at the code:
http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/ns4xPluginInstance.cpp#236
..looks like we return NS_ERROR_FAILURE to Necko through |OnStartBinding| if you
return anything but NPERR_NO_ERROR.

I wonder if using a better return value in our code would cause Necko to abort
the stream. Maybe one of these:
http://lxr.mozilla.org/mozilla/source/netwerk/base/public/nsIRequestObserver.idl#79

darin:
any error code returned from nsIRequestObserver::OnStartRequest or
nsIStreamListener::OnDataAvailable will cause necko to abort the stream. i'm not
sure how OnStartBinding is connected to necko's OnStartRequest/OnDataAvailable
methods.

----
OnStartBinding is called from OnStartRequest.

Ari, what happens if you return -1 to abort the stream from WriteReady/Write?

Comment 2

[Peter Lubczynski]

Per conversation with Ari---->WFM