879503 - NPP_StreamAsFile return wrong path

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[tuan_b918]

I have a plug-in that render and display document after download. But after updating to Firefox 20 or later, the plug-in no longer works.

With our plug-in we used NPP_NewStream and set NPMIMEType as NP_ASFILE. For some reason, on Firefox 20 or later, NPP_StreamAsFile return an incorrect path (C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\plugtmp-2\plugin-svrel.zhp). Firefox 19 or later return with the correct pathname (:\Documents and Settings\Administrator\Local Settings\Application Data\Mozilla\Firefox\Profiles\jpgiohcq.default\Cache\1\78\87C58d01)

Comment 1

[tuan_b918]

Should be Firefox 19 or older works.

Comment 2

[Masatoshi Kimura [:emk]]

What's the definition of "wrong"? AFAICT NPAPI doesn't guarantee anything about the location of the file.

Comment 3

[tuan_b918]

My question is why does NPP_StreamAsFile return different path on version 19 & 20?

Comment 4

[Benjamin Smedberg]

We no longer use our in-path file, because of changes in our cache implementation. Does the file you now receive have the correct contents?

Comment 5

[Benjamin Smedberg]

Sorry, "in-cache".

Comment 6

[tuan_b918]

The contents of the file is still correct. 

On Firefox 20, after the content gets download to the plugin path, it's move to the cache location. But because NPP_StreamAsFile state the file locates at the plugin path, our plugin no longer can find the file.

Comment 7

[Benjamin Smedberg]

The file passed to NPP_StreamAsFile is only valid until NPP_DestroyStream is called. If you need the file contents for a longer period, you are responsible for copying the file/data somewhere else.

Comment 8

[tuan_b918]

Anyway I can get the cache file location after it move to cache path? Process Monitor shows the file location, and I validate that the contents are correct.

Comment 9

[Benjamin Smedberg]

No. You should not be depending on the structure nor lifetime of our cache, and any code which did this in the past was probably subject to race conditions when files were evicted from the cache.

Comment 10

[tuan_b918]

Thank you Benjamin for your replies.

Has it always been the plugin responsible for handling the content after it gets download to a temp location? Our plugin code hasn't changed for many years. We have been depending on the browser to provide us where the file gets downloaded. Just curious if our design need to be revised.

Comment 11

[Benjamin Smedberg]

Yes, that has always been the case. It just happens that in many cases we handed you the path of the cache file, which tends to stay around for a while. But that was never guaranteed and is likely to have caused random errors in the past if the disk cache was near capacity.