Using Shockwave, I loaded a movie whose SRC was 24380 bytes long (a local file), and it aborted the stream before downloading the entire file. Logging the plugin methods called, I find : NPP_NewStream ( returns NPERR_NO_ERROR ) NPP_WriteReady ( returns 32678 ) NPP_Write ( offset 0, len 8192, returns 8192 ) NPP_DestroyStream ( movie won't play cause it ain't all there ! ) If I skip handling NPP_DestroyStream() I get NPP_NewStream ( returns NPERR_NO_ERROR ) NPP_WriteReady ( returns 32678 ) NPP_Write ( offset 0, len 8192, returns 8192 ) NPP_DestroyStream ( do nothing ) NPP_WriteReady ( returns 32678 ) NPP_Write ( offset 8192, len 8192, returns 8192 ) NPP_DestroyStream ( do nothing ) NPP_WriteReady ( returns 32678 ) NPP_Write ( offset 16384, len 8192, returns 8192 ) NPP_DestroyStream ( do nothing ) NPP_WriteReady ( returns 32678 ) NPP_Write ( offset 16384, len 7996, returns 7996 ) NPP_DestroyStream ( does the real stream end and movie plays ) Furthermore, if I alter my NPP_WriteReady() I get NPP_WriteReady ( returns 8000 ) NPP_Write ( offset 0, len 8000, returns 8000 ) NPP_WriteReady ( returns 8000 ) NPP_Write ( offset 8000, len 192, returns 192 ) NPP_DestroyStream ( altered to do nothing ) ... And so, I think NPP_DestroyStream() is being called when your buffer (8192) is consumed, in addition to when the stream en

Shrirang is now QA owner for Plug-ins; QA assigning all of my Plug-ins bugs over to him.

This seems to be a side effect of a workaround for the bug 13122.

Right, that's what I was looking at too. Let me do more testing before I check this in.

NPP_DestroyStream() is no longer invoked too often, but I will leave this open since it should be reviewd when AsFileOnly Plugin support arrives.

Latering

Reopening since disk cache has arrived, and marking dup of 23667.

*** This bug has been marked as a duplicate of 23667 ***

Reopening and adding dependency to bug 23667. See my comment in 23667.

Mass moving old milestone bugs to M16

M16 has been out for a while now, these bugs target milestones need to be updated.

Peter, can you check this bug against a recent build to see if it is still valid?

Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because the Netscape engineer it is assigned to is overburdened.

From the original comment "... aborted the stream before downloading the entire ...". This was fixed a long time ago (summer) ... clearly streams are downloading fully or none of the content would play.

This bug has been FIXED (probably a long time ago). NPP_DestroyStream should be called correctly now or 4.x plugins wouldn't be working.

marking verif based on earlier comments.