346332 - does no longer offer to open application/octet-stream attachments

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Magnus Melin [:mkmelin]]

When you recieve an email attachment with content type application/octet-stream, named test.doc I used to get option to open the attachment using openoffice, oowriter2 (default). Now it only shows me

"You have chosen to open 
test.doc
which is Microsoft Word Document
from mailbox://
Would you like to save this file?

This is highly annoying, should be fallout from bug 315536 (at least regressed 2006-07-13 -> 2006-07-23).

Comment 1

[Magnus Melin [:mkmelin]]

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

Comment 2

[Magnus Melin [:mkmelin]]

This is not of course thunderbird specific, try e.g. opening https://bugzilla.mozilla.org/attachment.cgi?id=232436&action=view with a firefox2 nightly, and it won't let you open the word doc without saving first, though in firefox1.5 it would.

Requesting blocking, the user experience of this is just awful imo.

Comment 3

[Scott MacGregor]

I agree this is pretty bad usability regression for mail, I'm no longer able to open most attachments anymore since this change happened without saving them first. 

Comment 4

[Mike Cowperthwaite]

Is this different from bug 347230 somehow?  The argument used to Invalidate that bug is: it used to be, you'd try to open one of these mislabelled attachments and get a dialog that only allowed you to save; now, you get "Save?" dialog.  What's the practical difference?

See my comment at bug 315536 comment 48.

Comment 5

[Magnus Melin [:mkmelin]]

No, I *did* get the option to open it straight away. And like in my example, it says it knows it's a "Microsoft Word Document", but still refuses to open it.

I don't think bug 347230 should be invalid. But either way, users consider attachments in mail to be a local file, so if the mime type doesn't give enough info, we should use the file extension.

Comment 6

[Mike Cowperthwaite]

(In reply to comment #5)
> No, I *did* get the option to open it straight away.

Hm.  I re-tested this with an alternate file, and it did give me the option to open.  I'm not completely sure what the difference was with my original test message -- I just picked a convenient one from my big box of test messages, where application/octet-stream was supplied for a .URL file, which is associated with my browser.

So, I've reopened that other bug with a comment on why it shouldn't have been invalidated.

Comment 7

[Joe Sabash [:JoeS1]]

Don't know when this started but in recent trunk builds, the same dialog
appears for attached or inline mp3 files. The mime type does not matter at all
See the following example of an attached mp3 source:
--------------010306060708080008030904
Content-Type: audio/mpeg;
 name="Eternals -  Babalus's Wedding DayFinal.mp3"
Content-Transfer-Encoding: base64
Content-ID: <[e-mail]>
Content-Disposition: inline;
 filename="Eternals -  Babalus's Wedding DayFinal.mp3"

It seems that just by virtue of the file extension, no option to play the file is offered. 

You can try it by attaching an mp to an email to yourself and try to open it.
Is this related to this bug , or should I open a new bug.

Comment 8

[Worcester12345]

Just now noticed this in a nightly branch build with .pdf files. Don't remember seeing it before today.

Comment 9

[Jean-Jacques Moreau]

Indeed this is quite annoying. Is a fix on the horizon?

Comment 10

[Mike Cowperthwaite]

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

Comment 11

[Magnus Melin [:mkmelin]]

FIXED on trunk by bug 347230 landing.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This bug is about Thunderbird version 2.0. How should it be fixed if the patch is only checked into the trunk? The version 2 beta 1 (20061211) is still affected by this issue. Trying to open an attachment with the Content-Type of application/octet-stream only shows me the save as dialog.

Reopening until it's fixed on 1.8 branch or version is changed to Trunk.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

All bugs, regardless of their version field, should be marked FIXED when they are fixed on the trunk. We use keywords to track branch fixes.

Comment 14

[Magnus Melin [:mkmelin]]

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

Comment 15

[Matthias Versen [:Matti]]

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

Comment 16

[Magnus Melin [:mkmelin]]

Bug 347230 landed on branch yesterday. This is working fine now.