192811 - Wrong app launches for some attachments

Status: RESOLVED WORKSFORME

(MailNews Core :: Attachments, defect)

Description

[selmer (gone)]

Using 1/30 trunk build, sometimes the wrong app is launched for powerpoint (and
possibly other) files.  Looking in the message source, I see 
Content-Type: application/octet-stream;
 name="Visit Schedule.ppt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="Visit Schedule.ppt"
which looks OK to me.  MScott suggested it may be that octet-stream is
overriding the file extension.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Do you have an entry in helper apps listing a helper for the
application/octet-stream type?

Comment 2

[selmer (gone)]

Yes, it's mapped to MS Word.  I don't know how it got there, is it necessary to
for .doc files to open properly?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> I don't know how it got there

That was a bug.  It's fixed...  If you delete that entry and make sure you use
builds that are no older than 1/20, you should be fine.

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

Comment 4

[Scott MacGregor]

Hmm, I'm going to re-open this. I deleted the octet stream entry that sneaked
into my list of helper app associations and now I still have a problem. I'm
opening an excel attachment and the helper app dialog comes up listing
octet-stream as the content type, instead of pre-selecting word excel. 

We've recently regressed such that the content type field is taking precedence
over the file extension for the suggested file name for the case of
octet-stream. We used to have special code which made sure we used the extension
if the content type was application/octet stream. 

Comment 5

[selmer (gone)]

I did the same as Scott and had the same problem with powerpoint.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Scott, you get the dialog and the "default application" listed is not Excel?

Here's the combination of problems we're trying to solve:

If a file is served as application/octet-stream and we attempt to do detection
on extension and detect it as "html" we don't want to kick it back to the
browser for loading (is this a good assumption?  Not sure).  So we put up the
dialog, but that says we can't handle text/html.  Which looks dumb.  The code at
http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#288
tries to handle this and a few related issues (see the comment).  In this case
that means the MIME type listed in the helper dialog is
"application/octet-stream" (but the correct helper should be preselected). 
Which means we have to disable the user's ability to mark the whole thing as
"don't ask again", since that leads to the problem selmer first encountered....

Another option is to make sure this code _never_ does a system or prefs lookup
on the type for application/octet-stream.  That would mean that people could not
add a default action through prefs (either "save" or opening in a helper that
they would like to use for any unknown content -- eg a virus checker).  That may
be a reasonable approach....

Thoughts?

Comment 7

[Scott MacGregor]

Hi Boris, to answer your first question, that's right. I get a helper app dialog
listing octet as the content type and the default action is save to disk. If I
select "Open With default Application", nothing happens. No attempt is made to
launch excel. Interestingly enough we are generating the correct moz-icon, I see
the excel icon in the helper app dialog. 

With regards to your second option, are you saying we would never do a system
look up on octet-stream, and would then fall back to looking up based on
extension? That  
could be a possibility.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> the default action is save to disk

The default action in this case is "save to disk" because of the
"content-disposition: attachment", perhaps....  See bug 98360; though I did not
think that mail attachments were affected by this (I seem to recall testing them
at the time and that header not being set on the channel that was going through
the uriloader).

> If I select "Open With default Application", nothing happens.

That's definitely wrong.  What is the "default application" listed on the
dialog?  (The option should not even be available if there's no default app.)

As for not doing a lookup, it's not a _system_ lookup that's a problem. It's a
lookup in our own prefs...

Comment 9

[Scott MacGregor]

Attachment: screen shot of my helper app dialog

Boris, here is a screen shot showing you what the helper app dialog looks like.

Comment 10

[Boris Zbarsky [:bzbarsky]]

That should not happen....  ccing someone else who may have ideas on what's
going on (I can start tracing code and trying to guess, but if someone who knows
the code can reproduce it's that much easier...)

Comment 11

[Boris Zbarsky [:bzbarsky]]

Oh, wait.  On Windows we treat all content as being "ok" to handle with the
"default handler".

So the problems here are:

1)  We're not finding the _real_ default handler for some reason
2)  We're not providing proper feedback when the user selects the "use default"
    option (it's _supposed_ to open the Windows application chooser if there is
    no real default handler, since we would call ::ShellExecute on the file....
    but that does not seem to be happening?).

My apologies for not being too useful; I have no Windows setup to test on.  :(

Comment 12

[Philip K. Warren]

While trying to reproduce here, I have sent myself an excel spreadsheet through
Lotus Notes which uses the following Content/Type, etc.:

Content-Type: application/X-MS-Excel; name="Book1.xls"
Content-Disposition: attachment; filename="Book1.xls"
Content-Transfer-Encoding: base64

Steps:

1) When I click on the attachment the first time, the Helper Application dialog
shows up with "Save to Disk" as the default action. I do see the MS Excel icon
in the Helper Application dialog. When I choose "Open it with the default
application" and click OK, I see a quick dialog box which appears and then hides
(must be download progress dialog), and then nothing happens. If I go to "Helper
Applications" in preferences, there is a type created for
"application/x-ms-excel" which specifies that it should be opened with the
default application. (Note: There is not an icon displayed in the preferences
for this file type, even though one appeared before)

2) When I click on the attachment subsequent times, Excel loads the document
properly.

When the MIME type is "application/octet-stream", we no longer save any settings
to mimeTypes.rdf with the checkin for Bug 189598, so it is as if we are stuck
endlessly in the first step.

For some reason the default helper application is not being launched in step 1,
and we need to isolate what is causing that problem to fix this bug.

This is with Build 2003021008 on Windows 2000.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Philip, see the patch in bug 193054.... that fixes the problem you are
describing (I was glad to have my old http content-disposition testcases lying
about.... ;) )

Comment 14

[Boris Zbarsky [:bzbarsky]]

OK.  Scott and selmer, could you retest with a Feb 14 build?  We should at the
least launch helpers now that bug 193054 is fixed; whether we launch the right
ones is the next question.  ;)

Comment 15

[selmer (gone)]

Looks better behaved on today's build except the default radio button is not to
launch the default app.  I have to click the radio button each time (which I did
not have to do previously.)

Comment 16

[Boris Zbarsky [:bzbarsky]]

See, here's the situation.  When IE encounters "content-disposition: attachment"
(for a part of a multipart/x-mixed-replace document, or for a toplevel
document), it puts up a filepicker so you can save the content.  When we
implemented that in Mozilla (bug 98360), I felt that putting up a filepicker was
a little harsh and made it instead open the helper app dialog, defaulted to "save".

The problem is that the channel mailnews creates for the attachment reports a
content-disposition (it's presumably an nsPartChannel, indistinguishable from
the case of multipart/x-mixed-replace content).  So it gets treated the same way.

I agree that this is totally wrong for mail attachments, though.  We need to
come up with a way to resolve that problem....

Scott, any ideas offhand? 

Comment 17

[(not reading, please use [e-mail] instead)]

moving onto my radar, so I can keep track of the bad mail issues.

Comment 18

[Samir Gehani]

Mail triage team: nsbeta1+/adt2

Comment 19

[Samir Gehani]

Over to Jan for a look.

Comment 20

[Mike Cowperthwaite]

Sorry if the CC's are unwelcome, but I'm not sure whether this bug should be WFM'd or not.  The default handling of application/octet-stream was, I thought, *supposed* to be "Save to disk" (per Scott's comment 4 et seq) because that 
type can be used (at least under Windows) to mask a possible executable.

Boris's comment 11, on the other hand, implies what seems to be the actual 
case, at least with Thunderbird: an application/octet-stream object may be "opened" by passing to the OS, which then handles it per the file extension.

And I guess there certain restricted extensions (or types?) which are 
disallowed from having "Open" selected on them because they appear on a list 
of "dangerous" extensions that MS published?  (e.g. .EXE .COM .SCR, and also 
.VSD -- Visio document -- but for some reason not .DOC, which is more 
dangerous than .VSD just due to ubiquity.)

Comment 21

[Boris Zbarsky [:bzbarsky]]

> an application/octet-stream object may be "opened" by passing to the OS, which
> then handles it per the file extension.

Correct.

> And I guess there certain restricted extensions

Correct.  On Windows, at least.

> because they appear on a list of "dangerous" extensions that MS published?

Dunno about the "MS published" part.  See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp&rev=1.298&mark=1765-1774,1782-1784#1764 and http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/io/nsLocalFileWin.cpp&rev=1.150&mark=2019-2064#2019

If you feel that extensions should be added to that list, please file bugs.

Comment 22

[Mike Cowperthwaite]

OK, then: this bug WFM with Seamonkey 1.0 (Win2K).  My test was an attachment with a .ZIP extension and application/octet-stream MIME type.  I removed my default application/octet-stream handler, then double-clicked the attachment.  It immediately offered to save to disk -- which is the default action I had 
assoc'd with .zip = application/zip.  I'm not sure I like this; extensions 
are not reliable predictors -- see bug 293804.

Then I removed the application/zip entry, and again double-clicked the attachment.  This time, the dialog popped up with:
  The file "info.zip" is of type application/octet-stream (WinZip File),
  and Seamonkey does not know <blah blah blah>
Offered to open with WinZip by default -- and, very nicely, the "Always 
perform this action..." checkbox is disabled, I presume because of the 
generic MIME type.  My sole quibble here is the wording that implies 
 app/o-s = WinZip File
which is also a similar situation to bug 293804.