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



12 years ago
11 years ago


(Reporter: Magnus Melin, Assigned: Scott MacGregor)


({regression, verified1.8.1.2})

regression, verified1.8.1.2
Dependency tree / graph
Bug Flags:
blocking-thunderbird2 +

Firefox Tracking Flags

(Not tracked)




12 years ago
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 
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

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

Comment 2

12 years ago
This is not of course thunderbird specific, try e.g. opening 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.
Flags: blocking-thunderbird2?
OS: Linux → All
Hardware: PC → All

Comment 3

12 years ago
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. 
Flags: blocking-thunderbird2? → blocking-thunderbird2+

Comment 4

12 years ago
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

12 years ago
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

12 years ago
(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.
Depends on: 347230

Comment 7

12 years ago
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:
Content-Type: audio/mpeg;
 name="Eternals -  Babalus's Wedding DayFinal.mp3"
Content-Transfer-Encoding: base64
Content-ID: <>
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

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

Comment 9

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

Comment 10

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

Comment 11

11 years ago
FIXED on trunk by bug 347230 landing.
Last Resolved: 11 years ago
Resolution: --- → FIXED
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.
Resolution: FIXED → ---
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.
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
Version: 2.0 → Trunk

Comment 14

11 years ago
*** Bug 364072 has been marked as a duplicate of this bug. ***
*** Bug 364564 has been marked as a duplicate of this bug. ***

Comment 16

11 years ago
Bug 347230 landed on branch yesterday. This is working fine now.
Keywords: fixed1.8.1.2
Keywords: fixed1.8.1.2 → verified1.8.1.2
You need to log in before you can comment on or make changes to this bug.