From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020109 BuildID: 2002010908 When I load the above URL, Mozilla starts up acroread, but nothing is shown inline i.e the plugin (nppdf.so) doesn't load the file inline. The same happens if I try to load the same document in another window or another tab. Reproducible: Always Steps to Reproduce: 1. Visit the above URL. 2. 3. Actual Results: Mozilla renders an empty page. Expected Results: Mozilla should render the document inline. I get the following warnings in the shell window. Warning: Actions not found: addBookmark, viewBookmark, copy, undefined-key, find, findAgain, history, loadImages, openURL, mailNew, new, openFile, print, exit, reload, saveAs, paste, delete, cut, undo, historyItem, back, forward, abort, PageUp, PageDown Warning: Actions not found: ManagerGadgetNextTabGroup, ManagerGadgetPrevTabGroup, DrawingAreaInput, addBookmark, viewBookmark, copy, undefined-key, find, findAgain, history, loadImages, openURL, mailNew, new, openFile, print, exit, reload, saveAs, paste, delete, cut, undo, historyItem, back, forward, abort, PageUp, PageDown Warning: No action proc named "ManagerGadgetArm" is registered for widget "form

If I try to use acroread as a helper instead of as a plugin I get a "File does not start with '%PDF-'" error. Indeed, the temp file created to run the viewer on is, according to the "file" utility: y2pxas25.pdf: gzip compressed data, deflated, original filename, last modified: Thu Nov 29 03:28:00 2001, max compression, os: Unix Looking at what the server actually sends us (NSPR_LOG_MODULES="nsHttp:5"): http response [ HTTP/1.0 200 OK Server: fnord/1.0 Content-Type: application/pdf Content-Encoding: gzip Content-Length: 76937 Last-Modified: Thu, 29 Nov 2001 08:28:00 GMT ] It looks like we never decode the data before feeding it to plugins and helpers..... Bill, would this be your bug?

Oh, sure, why not. I think we have to not turn off content encoding when we're going to open a helper app. But that might break when the data is of type application/zip and the helper app is something like winzip32.exe. Crap. Scott: Any advice?

Doesn't necko handle the case of content-type: application/zip and content-encoding: zip being set in the same header (that would be a bug in the server)? I know it does for Apache.... Darin?

nope... doesn't handle that case... does apache have the same bug with .zip files?

Not in the default config, because it does not do zip-encoding by default. But yes. Apache uses the same extension to set type _and_ encoding, it seems...

ok, then we probably need to duplicate the gzip logic for zip in nsHttpChannel.cpp. this has little to do with this bug though... so i'm going to file another to cover this issue.

see bug 119373.

OK. So we _always_ want to content-decode then. If it's of type application/zip it's not _encoded_ (hacks around Apache aside), just of a zipped type. So decoding will not change it.

exactly.

*** Bug 120540 has been marked as a duplicate of this bug. ***

--- Mass reassigning Unix bugs to serge ---

So... I think I may see a possible problem here.... The plugin stuff uses the nsICachingChannel interface of the HTTP channel to get at the raw data in the disk cache (nsICachingChannel.cacheFile). This raw data is stored content-encoded, iirc. So the plugin ends up reading encoded data from the cache.... Darin, am I completely on crack or would this fail as I describe?

bz: that does seem like the right explanation. yuck! it's going to be hard to fix this. we need to keep the cached content compressed to save on space, but more importantly to avoid having to recompress the data when the user asks to save it! consider a .tar.gz file for example... double yuck! one solution would be to make plugins use their backup mechanism (when the disk cache is disabled) for data sent with a Content-encoding header. that should be fairly easy to check... look for the place where SetCacheAsFile is called... notice that failures from that function are handled gracefully :-)

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

could this be a dup of bug 128199?

unfortunately, no. That bug touches none of the plugin code. That, and I still see this bug in a build with that patch. :)

is there any way we can apply similar logic here? seems like plugins should be treated similarly to helper apps... no?

Yeah. Except plugins should _always_ decode, imo. So should helper apps; the only reason the other code doesn't always decode for helper apps is that helper apps and saving share that codepath. But for plugins we always want to decode, since that's the equivalent of "showing the content".

agreed... looks like plugin doesn't directly call SetApplyConversion. is it using xfer or what? i'm a bit confused...

Well... I now have a patch that makes the pluginhost treat having a content-encoding header just like it treats a failure to set as a cache file.... and that isn't working. The temp file is created, and even has data in it, and I can open it with standalone acroread. But the plugin is failing anyway.

Bad code was making an assumption in two separate places... It was clobbering my nice filename in the PluginStreamInfo. The patch fixes this bug (as in, I can use the plugin to view that PDF, as well as other, non-encoded PDFs that I have lying around at file:// and http:// urls. The http:// ones do _not_ lead to temp file creation).

Here's is what I found debugging test case url 1) necko does the right thing with content-encoding: gzip 2) ns4xPluginStreamListener::OnDataAvailable() is getting correct decompressed stream from nsHTTPCompressConv::do_OnDataAvailable(), and we do feed acrobat plugin with that data, but it seems acrobat is waiting for NPP_StreamAsFile call, and we call it from ns4xPluginStreamListener::OnFileAvailable() and then every thing is going on exactly in the way bzbarsky explained in comment #12, acrobat chokes on gziped file from the cache:( I agree with darin's comment #13 we can explicitly force plugins to call SetupPluginCacheFile() to save already decoded stream into the plugin's local cache. I've try it in debugger - simply assigned rv=-1 on line #1968 http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/nsPluginHostImpl.c pp#1965 1965 if (cacheChannel) 1966 rv = cacheChannel->SetCacheAsFile(PR_TRUE); 1967 1968 if (NS_FAILED(rv)) { 1969 // The channel doesn't want to do our bidding, lets cache it to disk ourselves 1970 rv = SetupPluginCacheFile(channel); it works. The only questions are how we suppose to trigger that explicit caching, for what content-encoding and for which plugins? Perhaps we can use pref to specify this.

the patch looks workable to me. minor suggestion, I would use the old code here - if (cacheChannel) - rv = cacheChannel->SetCacheAsFile(PR_TRUE); I mean do not check for + if (useCacheAsFile) { + nsCOMPtr<nsICachingChannel> cacheChannel = do_QueryInterface(channel, &rv); in this case we'll save the file in the browser's cache and most likely we'll get it from there on the next access to file over http://

Shouldn't we just let our normal caching policies decide whether to cache the file? I'm fine with either way, though.

agreed, normal caching policies will do the right thing. over bzbarsky@mit.edu, your patch --> your bug.

Comment on attachment 72547 [details] [diff] [review] patch v1.0 r=serge

Comment on attachment 72547 [details] [diff] [review] patch v1.0 >Index: base/src/nsPluginHostImpl.cpp >+ // Now we look for a content-disposition header. If we find one, >+ // we can't use the cache as a file don't you mean content-encoding? otherwise looks good, sr=darin

Comment on attachment 72547 [details] [diff] [review] patch v1.0 a=asa (on behalf of drivers) for checkin to the 1.0 trunk

checked in on the trunk.

The link I mentioned works. But a similar link http://www1.bell-labs.com/user/cope/coplien.tiff.gz doesn't work. What I mean by doesn't work is: The file is a gzipped file. So when I am downloading it Mozilla should prompt me with a MIME entry of application/gzip or application/x-gzip. But Mozilla prompts me with a MIME of image/tiff. When I ask it to use a viewer like kview (which can display TIFF images), nothing happens and kview displays nothing. Indeed, if I go look in /tmp, the file is saved as coplien.tiff.gz and it's a gzipped image file. Why this confusing behaviour i.e telling me that it's a TIFF image while it's actually a gzip file. I don't have any helper applications set up for either gzip documents or TIFF images. I think that this is related to the content-encoding discussed here.

> So when I am downloading it Mozilla should prompt me > with a MIME entry of application/gzip or application/x-gzip Nope. The server says its image/tiff (with content-encoding gzip). I just tried that file, got the helper dialog, said to use "ee" and it opened fine. Please make sure you're using a recent build (like last two-three days) and if it's broken in that please open a _new_ bug and cc me. re-resolving this bug, which covered a very specific plugin-related issue... Thanks, Boris

wfm