From: http://bugzilla.mozilla.org/show_bug.cgi?id=20655 Changing content-dispostion for an attachment, like text or HTML, could be added to a context menu to the attachment box in the compose window. The context menu could look something like: Advanced->Content-Dispostion->Inline [ ] Attachment [x]
*** Bug 67160 has been marked as a duplicate of this bug. ***
gemal, next time, please note the bug no. in the other bug. ------- Additional Comments From Ben Bucksch 2001-01-31 04:08 ------- This is important, since Lotus Notes and Eudora both seem to have problems with recieving inline attachment (or they follow the spec closer, whatever your opinion is).
Perhaps attachments could have an `Attachment Properties' dialog, in which you could specify: * the filename (so you could rename `Balance_Sheet_For_Our_Dumbest_Client.xls' without having to rename the file on disk before you attached it); * the Content-disposition; * the Content-description (so you could give attachments useful descriptions, instead of having `Unknown Document' all the time).
This probably means that we need a context menu, which is a good idea anyway - the only way to delete an attachment (that I could figure out) is the keyboard. Not very good. Maybe we should file an extra bug for that and make this one depend on that one?
The context menu could have the followin: - Remove all attachments - Add another attachment - Remove selected attachment - Open selected attachment (seen in Outlook Express) - Print selected attachment (seen in Outlook Express) - Rename selected attachment - Advanced -> Content-Dispostion -> Inline [ ] Attachment [x] - Advanced -> Content-Description -> Set Change perhaps even "Content-Transfer-Encoding" ????
Don't you also want to be able to set Content-Type (at least for advanced users)? Deducing content type from the file suffix doesn't work well on Unix so it's often necessary to fix things up.
To Esther ..
I filed a bug 72116 about setting a charset to attachments. There, I proposed a dialog. I didn't know about this, but if we allow many things to be set, probably a dialog is better.
CC'ing jgmyers to see if he has any comments from standards point of view.
*** Bug 95372 has been marked as a duplicate of this bug. ***
See bug 54940 which is related. Setting content-dispostion of coutgoing attachments on a case-by-case basis becomes a lot less... necessary... when the mailer has a comprehensive list of mimetype-to-file-extension mappings available to it. Mailers--except Mozilla/NS6--always ship with--or have access to--a fairly exhaustive list that even encompasses filetypes not usually found on a given platform. I have a sneaking suspicion that if mimeTypes.rdf and the fallback code to OS-level registries and mailcaps mapped file extensions to the appropriate mimetype during message composition, 98% of the problems people have on the receiving end would disappear.
Reassign to varada
Jumping in really late here... Mr. Koppelman seems to be confused. Content-Disposition has nothing to do with file type (that's what Content-Type is for), it has to do with whether the attachment should be viewed as inline (that is, appearing along with the main message) or as an attachment (so it must be opened separately).
*** Bug 151256 has been marked as a duplicate of this bug. ***
I agree with Mr. Wallace. In fact, I wish the default behaviour was for all attachments to NOT be inline. Particularly, the default behaviour of text files should be NOT inline! Having a UI to change the default behaviour per attachment would also be useful. I make my case in bug #151256
I hope the solution is a check box that the users sees as they attach the file, rather than just a context menu where they can change the setting AFTER the file is attached. I would also like to see the a checkbox in the GUI mailnews preferences dialog to define the default behavior. I have nothing against the context menu, but most of my users wouldn't think to try that.
taking all of varada's bugs.
*** Bug 201564 has been marked as a duplicate of this bug. ***
*** Bug 219584 has been marked as a duplicate of this bug. ***
This would be great. I was originally just for the charset specification, but all of these options could be useful. What about changing the summary, to include not only content-disposition but also all the other attributes?
*** Bug 212882 has been marked as a duplicate of this bug. ***
See also bug 192262.
I am all for the UI, however when reading this bug I am wondering, how else should attachments be sent except for as "attachments"? The fact that we need the UI at all comes from the fact that the default behavior is to send them inline... if the original coder had chosen to send the as attachment we wouldn't be talking about adding UI. Please refer also to bug 65794 for a discussion of how attachments should be sent by default
*** Bug 265658 has been marked as a duplicate of this bug. ***
Instead of having a whole UI/Dialog box for setting the status, why not use the intuitiveness of the composition determine the disposition: If the file is dragged into the attachment pane or added via attach->file, it should be attached as attachment. If it is dragged into the body of the message, make it inline. This would follow the intent of the composer, and if you really need to tweak it for power users, have a menu or context driven dialog, but this method should fix most cases rather transparently.
Instead of having a whole UI/Dialog box for setting the status, why not use the intuitiveness of the composition determine the disposition: If the file is dragged into the attachment pane or added via attach->file, it should be attached as attachment. If it is dragged into the body of the message, make it inline. This would follow the intent of the composer, and if you really need to tweak it for power users, have a menu or context driven dialog, but this method should fix most cases rather transparently. In the meantime, since Mozilla properly shows both inline and attachment dispositions inline if enabled, why not as a simple/quick fix set the default to as attachment, then allow the exception of the dragged-in file to set it to inline.
Bug 248639, seems related to this one, but I'm not positive that it is a complete duplicate. What I believe to be true, is that *if* this UI was implemented then that would render the aforementioned bug obsolete.
I think we need a attachment properties UI where we can change its properties. In addition to the other bugs mentioned, it would also help bug 220646 . NOt that I care if the forwarded message has an extension, unless the subject happens to end in ".com" which causes problems for me.
For me, every time an attachment to an outgoing message (using Eudora, Messenger or Thunderbird) has invisibly become inlined, it has been a memorable, negative experience. (In my experience, one of the biggest uses of zip attachments has been to avoid inlining!) I support the thinking that drag and drop attachments must be sent as attachments because that is how it was composed. This might not be the intention of "content-dispostion: inline", but the sender has no guarantees about the recipient's MIME handling configuration. The remark on bug 65794 that if you want to compose a message with inline content, use HTML, is on target. Trying to compose a multimedia message via "content-dispostion: inline" was a good idea in 1991 (NeXT had inter-paragraph voice recordings), but it did not come into common usage and has been completely superceded by HTML email.
*** Bug 328266 has been marked as a duplicate of this bug. ***
Can anything be done about this bug ? I cannot use Seamonkey mailer to send files to corporate users, that use LotusNotes, just because attachment became "inline" - they get some awkward filenames. Why was that changed ? For a long time it was ok, files were attached as attachments. Situation is explained in: https://bugzilla.mozilla.org/show_bug.cgi?id=328266
Bug 65794 has fix written to add a UI (and for some reason Mscott has given it a "-"). Can we kill both bugs with this one check in until we find another solution that fixes it without needing the UI (like the MIME type mapping suggestion of some other folks)?
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Filter on "Nobody_NScomTLD_20080620"
(In reply to comment #33) > Bug 65794 has fix written to add a UI (and for some reason Mscott has given it > a "-"). Can we kill both bugs with this one check in until we find another > solution that fixes it without needing the UI (like the MIME type mapping > suggestion of some other folks)? Some updates: (1) bug 65794 has been resolved today with a minimal fix to set the default for sending attachments with an "attachment" content disposition; (2) including a UI element for the global preferences also is part of a patch in bug 445088 (rather accidentally, not knowing that it was proposed before); (3) the MIME and user-interaction ideas are spun off to bug 452092 now.
I'm not so sure we actually want this, at all. Anyway, wanted‑thunderbird3-
OK, this bug here originally had a pretty narrow scope: add a context menu item for content disposition. I wholly agree with that. Currently this bug here depends on bug 452092, which has a much wider scope, talking a lot about preferences based on extension, mime type, drag target or adressee. But as there are no rules without exception, a UI to override any such decision will be useful. So please, let's have that, without waiting for bug 452092 to find a consensus for all thos possible ways of obtaining a default. (In reply to Henrik Gemal from comment #0) > The context menu could look something like: > Advanced->Content-Dispostion->Inline [ ] > Attachment [x] A simpler solution: avoid the first two levels, and simply add a menu item labeled "inline" to the context menu, with a check mark if the attachment will be sent inline. (In reply to Ben Bucksch (:BenB) from comment #4) > This probably means that we need a context menu, which is a good idea anyway Not sure when this was introduced, but the attachments in my Thunderbird 8 do have a context menu, containing Open, Remove, Rename and Select All. (In reply to Matthew Paul Thomas from comment #3) > Perhaps attachments could have an `Attachment Properties' dialog [...] A powerful dialog might make sense, but would almost certainly be more work. So perhaps it would be best to have a single additional context menu item added for this bug here, and request a more powerful dialog in a separate enhancement request. (In reply to Michael Baffoni from comment #26) > why not use the intuitiveness of the composition determine the disposition. That's what bug 452092 is discussing. While I can see the point, there are people like me who don't use a graphical file manager, therefore don't drag&drop files, and still want to be able to send files inline or as attachments. So there still should be a way to override any default associated with that method. So let's stick to an UI to override any default here. (In reply to Magnus Melin from comment #37) > I'm not so sure we actually want this, at all. Do 25 votes count for something in this respect?
(In reply to Martin von Gagern from comment #38) > Currently this bug here depends on bug 452092, which has a much wider scope, > talking a lot about preferences based on extension, mime type, drag target > or adressee. But as there are no rules without exception, a UI to override > any such decision will be useful. I'd agree with that statement, even an intuitive way to specify the content disposition should have a way to verify and possibly correct the choice made automatically. Note that this is not a "hard" dependency, merely to indicate that any broader solution implemented in the other bug may require a change of what's intended here. > have a single additional context menu item added for this bug here That sounds like a good preliminary solution, adding an item "Show inline" as a checkbox menuitem and make it checked for a Content-Disposition: inline. Remembering from bug 525955, the content disposition is currently based on the value of mail.content_disposition_type along with a couple of attachment-specific properties, but cannot be set explicitly for each MIME part separately. Thus, even such a context menu option would require some work extending the parameters passed to nsMsgCompUtils::mime_generate_attachment_headers() and any related classes or structs, thus would require some of the work suggested in bug 452092.
A more simple way to look at it is from the end-user view: Either documents and stuff (zips) are attached and displayed as attachments. Or images and such are part of the message body (for example by dragging it into the edit box) and are then to be displayed inline (as part of the message body). That the mime protocol allows to mix these things makes it confusing for lots of people (see bug 269273), mail systems and applications. So please keep it simple, and don't invest in such advanced controls... Note, currently only images can be dragged into message body (causing them to be attached with a <img> tag displaying it in the message). But it could be nice to also include other objects in the same way: attach inline but with an icon (and filename) in the message body. But that is another issue.