From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) BuildID: When I download a file from our Viewpoint plugin, and leave the browser page (hit back) while a file is being streamed in, the plugin receives NPP_DestroyStream, as expected. However, the NPReason passed in is NPRES_DONE. This causes all sorts of problems- for example, we try to process/uncompress a file / install a component dll that is not a complete file. (Can cause a crash). I noticed that in ns4xPluginStreamListener::CleanUpStream(), above the destroystream call: NS_TRY_SAFE_CALL_RETURN(error, CallNPP_DestroyStreamProc(callbacks- >destroystream, npp, &mNPStream, NPRES_DONE), lib); there is a comment: // XXX need to convert status to NPReason Is that related? Reproducible: Always Steps to Reproduce: 1.Install Viewpoint plugin (http://cole.viewpoint.com/~aberger/setwindowbug/viewpointplugin.zip) 2.Delete one of our dlls (eg from program files\viewpoint\viewpoint media player\components\SceneComponent.dll) so that when you view content, the plugin will try to redownload it. Note that you can see the same behaviour when leaving the page when downloading content, but the components are much bigger and so it is easier to cancel while the stream is open). 3.View any of our content: http://cole.viewpoint.com/~aberger/setwindowbug/index.html Actual Results: when you leave the page, we will (probably) throw off a bunch of exceptions when trying to uncompress the (incomplete) file and hopefully not (but possibly) crash.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows NT → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla0.9.7
Created attachment 61809 [details] [diff] [review] patch Here's a patch that should send a different NPReason in NPP_DestryStream based on if the plugin is being destroy (i.e. leaving the page) or Necko tells us it's complete. Ari, I had a hard time testing this with your plugin. It didn't look like any more streams opened after getting a text file. However, I did test this on Disney.com, which has a rather large flash animation. I hit back before it was completely downloaded and noticed NPRES_USER_BREAK being sent. If I waited, the normal NPRES_DONE was sent. If possible, can you test this patch and let me know if it fixes things? Thanks!
Thanks Peter- The patch seems to work for me. I am getting the cancelled message correctly now.
Comment on attachment 61809 [details] [diff] [review] patch sr=attinasi
Attachment #61809 - Flags: superreview+
please hit the 0.9.4 branch w/ this after trunk landing. once it's there add "fixed0.9.4" in the keyword field.
Keywords: edt0.9.4 → edt0.9.4+
this just went in.
patch in trunk and 0.9.4 branch, marking fixed and nominating for mozilla 0.9.7 for API compatibility
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
a=asa (on behalf of drivers) for checkin to 0.9.7
Keywords: mozilla0.9.7 → mozilla0.9.7+
checked in debugger that NPRES_USER_BREAK is called ('2' is returned) when I leave the page with viewpoint plugin and NPRES_DONE ('0') is not called. Both trunk and branch work. Marking VERIFIED.
Status: RESOLVED → VERIFIED
adding keyword 'verified0.9.4'
Keywords: verified0.9.4, verified0.9.7
You need to log in before you can comment on or make changes to this bug.