I've set up Mozilla to use acroread to view PDF files, and it works great on web pages: click a PDF link, and it suggests `Open with application acroread'. But when browsing a CD-ROM, it doesn't see this association. Click a PDF link, and it can only suggest `Save to disk'. (I copied the CD-ROM html and pdf files to /tmp, and it does the same thing.) Steps: 1. Set up Mozilla to use a helper app, like acroread for PDF files. 2. Confirm it works on the web by clicking on a PDF link. It will suggest acroread. 3. Try clicking on a PDF link in a local file (file://...). It will suggest saving the file.

se, who should own this? is it law? or possibly a necko issue?

->bill. i'll check this...

I can't reproduce this. I did have to hide my Acrobat plugin or else it tried to use the plugin (which doesn't seem to work today). I get "Open using application acrord32.exe" for both http: and file: access to a document (I'm on Windows). What mime type does the dialog say it has in each of these two cases?

The dialog says it's application/octet-stream for the local one, and application/pdf for the remote one. Okay, shoot me. I should have done this before, but I just tried it with Mozilla 0.9 on Windows 2000 and it indeed works. I guess it's Linux-specific. (Mac, anybody?) I would guess this is because Windows tends to know what app it should open a document with, and on Linux it needs to be told, i.e., opening something that requires a helper app from a local disk is like double- clicking it, and Mozilla just says to the OS "open this file". But that's just a guess. I'd say on Unix, at least, it should check the file types the user specifies under helper apps for the filename extension.

Mac calls the OS (well, Internet Config, but part of MacOS since 8.5 or 8.6) to look up the file type if it can't determine what it is. Bug 64703 deals with the fact that if mozilla can't figure out the type, it puts up the unknown content dialog for LOCAL FILES. I came up with a mac specific hack, but probably could whip something up xp. However, that wouldn't necessariliy fix this bug. Why aren't we looking into helper apps prefs for the mapping?

bah, there's a bug for us integrating w/ gnome/mailcap/kde's mime systems. And yes, there's win32 code to do the checking which is why this is pp

timeless, would that be bug 52441?

I don't think there's code in the uriloader/exthandler that looks up file extensions in the prefs mimeTypes.rdf datasource (although I've heard rumors about there being such code). That's more RDF magic than I could conjure up, but certainly it could be done. There should be a bug on that (or, one that has us remove the "extensions" field from the pref entries :-). Does anybody know if there is one already?

yes that's the bug i was looking for.

I guess it goes without saying that it doesn't work for FTP, either (though it didn't occur to me until after I tried it).

Dupe of bug 81654 (or vice versa)?

shrir, could this be related/dup of bug 81654?

might be..

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

after scanning through bugs, i've concluded this bug is indeed a reasonable dupe. yes ftp is basically the same as file because the protocol doesn't suggest a mimetype so we have the same problem and can use use the same solution. *** This bug has been marked as a duplicate of 52441 ***

VERIFIED: ->networking,qa to me.