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).
*** Bug 346905 has been marked as a duplicate of this bug. ***
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.
OS: Linux → All
Hardware: PC → All
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+
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.
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.
(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
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: <email@example.com> 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.
Just now noticed this in a nightly branch build with .pdf files. Don't remember seeing it before today.
Indeed this is quite annoying. Is a fix on the horizon?
*** Bug 361264 has been marked as a duplicate of this bug. ***
FIXED on trunk by bug 347230 landing.
Status: NEW → RESOLVED
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.
Status: RESOLVED → REOPENED
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.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago → 11 years ago
Resolution: --- → FIXED
*** Bug 364072 has been marked as a duplicate of this bug. ***
*** Bug 364564 has been marked as a duplicate of this bug. ***
Bug 347230 landed on branch yesterday. This is working fine now.
You need to log in before you can comment on or make changes to this bug.