Open Bug 452092 Opened 16 years ago Updated 2 years ago

Determine content disposition for attachments from MIME type and interaction

Categories

(MailNews Core :: Composition, enhancement)

Product:
MailNews Core
Component:
Composition
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: rsx11m.pub, Unassigned)

References

(Blocks 3 open bugs)

Details

This is a spin-off from bug 65794, in which various methods have been discussed to specify the content disposition depending on the type of the attachment and the way how it is added to the message when composing. The fix for bug 65794 was restricted to just changing the default for now without considering the further improvements which could be implemented.

(Quoting bug 65794 comment #79)
> In general, only attachments that can be usefully interpreted and displayed
> inline should be able to get that disposition. So, if there is no suitable
> method to display it inline (which could be defined by some inlinable content
> type list), it should go out with an "attachment" disposition regardless of the
> mail.content_disposition_type preference. I wouldn't mind retaining its default
> "inline" as long as non-inlinable attachments (e.g., PDF or Word files) are
> sent with an "attachment" disposition.
> 
> (In reply to bug 65794 comment #64 and bug 65794 comment #78)
> > I've always thought that anything that shows up in the attachment box of
> > the compose window (...) should show up as an attachment, and anything
> > dragged/copied/inserted into the body should be inline;
> 
> Some attachments can be considered a substantial part of the message, and
> therefore should be included when displayed and replied to, whereas others are
> "true" attachments in nature, even if their MIME types are identical. Thus, it
> sounds like a good idea to make this decision individually selectable for an
> attachment, rather than basing it on a global pref alone. Keep in mind though
> that the drag-into-message-body semantics is already taken by a third type of
> attachment: Adding it as part of the HTML message within a "multipart/related"
> rather than "multipart/mixed" top content type. This works well for images, but
> is rather broken for text (bug 113435).
> 
> Expanding on your suggestion:
> (a) Drag-and-drop of text/plain, text/html, and message/rfc822 attachments into
> the message body will cause them to be attached with a disposition of "inline"
> (solving bug 113435 in the process);
> (b) drag-and-drop of image/* attachments into the message body (1) attaches
> them as "inline" if the message is composed in plain-text mode, or (2) embeds
> them into the message for HTML mode;
> (c) any files of those MIME types dragged into the attachment area attaches
> them with a disposition according to mail.content_disposition_type (which could
> be "1" by default then);
> (d) any other file types (which likely cannot be displayed inline) are attached
> with "attachment" disposition.

There are several similar variants in that bug report that could be considered to make the attachment disposition for outgoing messages more practical.
Following noteworthy proposal from bug 65794 comment #74 (excerpt):

> 1bis) Make a list of all kind of files and discuss about the corresponding
> "inline" or "attachment" default behavior for each.
> 2) Add a functionality that would allow the user to manage the "inline" or
> "attachment" choice for each file type.

> ... add an "Attach files as" setting with those possibilities:
> "Auto"/"Attachment"/"Inline". Selecting "Auto" enables a button "Manage" on the
> same line, on the left. Clicking on "Manage" button allow the user to set the
> "Inline" or "Attachment" behaviour for each file type

The 2nd part could be implemented in mimeTypes.rdf, allowing the user to specify the default content disposition based on the MIME type (or file extension) rather than by a fixed list of inline-"feasible" attachment types.
I agree with those behaviors as it applies to using the file\attach\file... menu or the Attach->file menu button.  However, I would prefer any drag and drop behavior for a setting of "Auto" to set disposition based on the area the file is dragged to, so that it corresponds to the equivalent location by the receiver of the message:  If the file is dragged into the address/attachment area, it should be attached as disposition:attachment; if dragged directly into the body of the message, it should be attached as disposition:inline.  This would make the behavior more intuitive to the action.  Any override setting to attachment or Inline should supersede D&D behavior.  Does that make sense, or are there good reasons not to follow that UI behavior?
I agree that the drag-and-drop behavior would be the most conclusive indicator of the user's intent. Having a configurable list of MIME types or file extensions for the case (b) or as default when using the menu to attach would help in cases where we don't have that clue. So yes, this makes sense.
> If the file is dragged into the address/attachment area,
> it should be attached as disposition:attachment; if dragged
> directly into the body of the message, it should be attached
> as disposition:inline.

While this seems like a correct solution, and intuitive and easy, it is not in reality.
This annoys me terribly about MS WordPad: I drag a file over the editor (of course the content pane, because it's the largest part of the window), and it attaches the file inline, although I wanted to open it. I have to drag the file into the toolbar, then it opens in WordPad, but that's unpractical, because the drop area is too small and usually hidden.
In our case, it's even worse: the attachment pane is hidden by default, in addition to being smaller than the text area.

I don't think users make such fine differences in their mind, between embedded in text, Content-Disposition: inline (attachment, but shown after the msg content) and Content-Disposition: attachment (attachment, not shown at all, need external application). I don't think the sender thinks about this at all. (I think the *receiver* does, though, so the reader software should be flexible, but that's not the subject of this bug, and we need to do the right thing for other recipient software.)
I think we should just "do the right thing" based on attachment file type alone. People do expect text and image attachments to show inline, and PowerPoint doesn't make much sense inline. So, just pick the "right" disposition per file type, and allow the advanced user to change it (bug 66915).
> drop area is too small and usually hidden.

s/hidden/covered by the Explorer window from which I drag/
Guess I found the first "victim" of the new Content-Disposition default: Forwarding an e-mail as attachment will make it a real message/rfc822 attachment. Trying to view it, e.g., in the Gmail web interface won't show the content of the forwarded message as before, just a "View" and a "Download" action link. Clicking the "View" link will present it as the raw RFC-822 encoding, thus essentially unusable for the recipient. Now, one may (correctly) argue that this is Gmail's fault, but would be a reason to send message attachments with an "inline" deposition, at least when forwarded.

(In reply to comment #4)
> I don't think users make such fine differences in their mind, between embedded
> in text, Content-Disposition: inline (attachment, but shown after the msg
> content) and Content-Disposition: attachment (attachment, not shown at all,
> need external application). I don't think the sender thinks about this at all.

The user already has to do it when composing HTML messages and, e.g., wants to add an image from a file using drag-and-drop. This would only be extended to plain-text messages then as well.

> I think we should just "do the right thing" based on attachment file type
> alone. People do expect text and image attachments to show inline, and
> PowerPoint doesn't make much sense inline.

This is why I distinguished cases (b) and (c) in my list above. I still think that non-whitelisted attachment types should be sent with an attachment deposition no matter what. However, based on the quote in comment #1, rather than having a fixed list of such MIME types and file extensions, this could be user configurable. Thus, if a user wants to attach a "fromMyApplication.etc" file he or she would consider inlinable, the respective type for ".etc" files could be added to that list to get this disposition for future attachments.
(In reply to comment #4)
> This annoys me terribly about MS WordPad: I drag a file over the editor (of
> course the content pane, because it's the largest part of the window), and it
> attaches the file inline, although I wanted to open it. I have to drag the file
> into the toolbar, then it opens in WordPad, but that's unpractical, because the
> drop area is too small and usually hidden.

I understand that issue, which is why I mentioned that it should be either attachment OR the address area - the address area is never too small to drag to so you shouldn't run into the same scope of problem.

> I don't think users make such fine differences in their mind, between embedded
> in text, Content-Disposition: inline (attachment, but shown after the msg
> content) and Content-Disposition: attachment (attachment, not shown at all,
> need external application). I don't think the sender thinks about this at all.
> (I think the *receiver* does, though, so the reader software should be
> flexible, but that's not the subject of this bug, and we need to do the right
> thing for other recipient software.)
I agree that the user doesn't think about it - they pretty much want it to show up the way they compose it.  So if they drag a file into the body (e.g. an image) and start resizing it, I bet they want it to be inline.  If they drag it onto the page so it shows up in a bulk list of attachments, I bet that is the way they want the receiver to see it.
> I think we should just "do the right thing" based on attachment file type
> alone. People do expect text and image attachments to show inline, and
> PowerPoint doesn't make much sense inline. So, just pick the "right"
> disposition per file type, and allow the advanced user to change it (bug
> 66915).
> 
I agree that is a fine behavior for non D&D attachments.  I think however that the simple act of dragging and letting go in a specific area of the GUI is enough of a show of intent that the behavior should follow that intent.  Whenever possible, you _do_ want WYSIWYG.

(In reply to comment #7)
> I agree that the user doesn't think about it - they pretty much want it to show
> up the way they compose it.  So if they drag a file into the body (e.g. an
> image) and start resizing it, I bet they want it to be inline.  If they drag it
> onto the page so it shows up in a bulk list of attachments, I bet that is the
> way they want the receiver to see it.
> ... 
> Whenever possible, you _do_ want WYSIWYG.

This opens a (possibly) new idea to make this intuitive. When composing an HTML message and dropping an image into it, the image is visible as a feedback to the user. Similarly, when composing in plain-text mode, or adding an attachment that cannot be inlined or embedded into the HTML code itself, the contents of an inline attachment could be appended (as read only) to the message in the composition window when dragged there. In contrast, "true" attachments end up in the attachment box. In this way, the user would see immediately that he or she has just attached the 5MB log file inline rather than as attachment.

(In reply to comment #6)
> Guess I found the first "victim" of the new Content-Disposition default:
> Forwarding an e-mail as attachment will make it a real message/rfc822
> attachment. Trying to view it, e.g., in the Gmail web interface won't show the
> content 

Yep. This definitely should block the bug 65794 "fix"
I agree with the WYSIWYG sentiment for the general case.  For the specific case of huge files, I wonder if we actually want to do something different, since the performance is likely to be so bad as to make the user-experience pretty rotten.
How about something similar to the script timer; if it takes more than 30 seconds to display inline content in the composer, a window pops up noting the performance issue, and asking if the content should be added as attachment?
The problem I would see here is that an 1MB image may be "huge" for one user but "just right" for somebody else, thus I don't think a strict limit can be defined when an image would be considered too large for an inline display.

Rather than a modal dialog, maybe add the size (which is known at the time of inserting the image, or any other attachment for that matter) of the image so that it appears, e.g., when hovering over it, then allow the user to change the disposition if he or she thinks that it may be too big for an inline display.
Blocks: 462266
Related: There is also bug 294763 on the inline/size issue, however on the display side, whereas this discussion here is about composition.
I am new to this discussion and want to take a slightly different slant on it.  One of the objectives for Thuderbird 3 is to increase take up of it.

All the discussions above make sense to readers who are computer literate and understand the make up of e-mails.

If take up of Thuderbird is to increase its method of use must default to the lowest common denominator (i.e. behave like Outlook and Outlook Express for common operations).  To achieve this all files dragged to any part of the compose window should default to attachment.

Skilled users who understand what they are doing should be given the ability to set their default preferences to other actions.  In this way both the unskilled and skilled user are catered for.
Blocks: 334622
I'm adding bug 335783 as a dependency, which would add pasting from the clipboard directly into an attachment to the mix.
Blocks: 335783
I send patches (text/x-patch) via email using attachments to avoid word-wrap problems, and only just noticed the change in default.  I would like to be able to create an inline attachment via the keyboard.  For the moment I guess I'll just change the default back.
Attaching a patch should absolutely result in an inline disposition since it is mostly meant to be reviewed, and thus, people reading the message damn well should be able to see the changes without having to save the attachment and open it in an external editor.
(In reply to comment #18)
> Attaching a patch should absolutely result in an inline disposition since it is
> mostly meant to be reviewed, and thus, people reading the message damn well
> should be able to see the changes without having to save the attachment and
> open it in an external editor.

I've specifically had requests to *not* attach patches as inline because it screws up email clients (e.g. Apple Mail), so it's not as simple at this.
How does it "screw up" the client?  Any "screw up" beyond the client actually showing the attachment in line is a bug in that client and should be fixed there.  Forcing the disposition to be non inline screws up EVERY client since you explicitly tell them not to show the user the content of the file, when they really want to see it.
You'll have to ask the clang developers for more specific information, but it's mentioned explicitly in their developer policies: http://llvm.org/docs/DeveloperPolicy.html#patches
Guys, that's exactly what this bug is about! You can't handle all attachments as equal, and different people have different preferences.

Defining the content disposition by registered MIME type and/or file extension, or by the user's drag-and-drop behavior would make *both* of you happy... :-)
This advice makes no sense.  You WANT to be able to see the patch inline so you can actually read it without having to save it and load it in an external editor.  They seem to be saying that apple mail won't let them save the attachment at all; treating it as if you had just pasted the text into the body of the message.  If so, that is a bug in apple mail that should be fixed, and can easily be worked around by just saving the entire mail message.  Patch will happily ignore any commentary in the message before the start of the patch header.  You should not break functionality for everyone else just because apple screws it up.

FYI, everyone posting patches to LKML uses inline.

And fsx11m, we are talking about the same file type, so differentiating based on mime type isn't the issue, though having the ability to specify the disposition when attaching the file would probably be best.
Phillip: Making this a customizable per-type list was proposed in the bug which just switched the default disposition, and I sure agree with that proposal:

(In reply to comment #1)
> Following noteworthy proposal from bug 65794 comment #74 (excerpt):
> > 1bis) Make a list of all kind of files and discuss about the corresponding
> > "inline" or "attachment" default behavior for each.
> > 2) Add a functionality that would allow the user to manage the "inline" or
> > "attachment" choice for each file type.
rsx11m: that would not affect this use case since there is only one type we are talking about: text/x-patch.

The question is, should that default to inline or not.
Phillip Susi, he's proposing to make it customizable by the user. So *you* decide how your patches get sent.

Time, now, to review?

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.