This is a follow-up on bug 384599 and for parity with SeaMonkey bug 441659. Quoting steeve (bug 384599 comment #12) > Is there anyway that thunderbird can mark an attachment as 'inline' when > sending? Not that I see. Quoting dmose (bug384599 comment #14) > steeve: good point, it might well be worth having UI of some sort to do that. > Apparently Eudora Classic has it. File a spin-off bug? Based on bug 429143 comment #12, a UI element for quoting inline attachments in replies is suggested in the Composition preference pane for SeaMonkey. In contrast, Thunderbird has a dedicated Attachments pane, which is currently only about half used. Putting the UI for these two attachment-related preferences into an "Outgoing Messages" section of the Attachments pane appears to be intuitive. This would also provide a workaround for the content-disposition issue in bug 65794. While a more comprehensive solution than just the preference is desired in that bug, the presented scenarios would still depend on the disposition pref to a certain extent. Thus, this wouldn't prevent any larger solution.
Created attachment 329388 [details] [diff] [review] Proposed patch The XUL part is fairly straight forward, I tried to be as descriptive as possible for the strings to make it clear to the user what those options mean. A drop-down list was chosen similar to the inline/attachment element in the Composition pane.
I'm a bit hesitant this needs UI. But if it does, the disposition text would need to take into consideration that that it's only "When possible, ..." (or something) as it just applies to a few types. And FWIW, I think the default pref for those is wrong.
> (comment #3) I'm a bit hesitant this needs UI. Are you talking about both preferences or just mail.content_disposition_type? For mail.reply_quote_inline, it would be good to have this visible so that people who want to use the feature to get back to the old behavior actually find it at an intuitive place. The Attachments pane currently offers a lot of empty space. Likely though, I wouldn't have included the content disposition if steeve and Dan hadn't mentioned it in bug 384599. > "When possible, ..." (or something) as it just applies to a few types. These are two different issues, one is how we are sending out the attachments (strictly defined by that preference) and how the receiving client displays it. If you prefer a more careful phrasing, I'd suggest "If supported, ..." to make it more apparent that this is beyond the sender's control. > And FWIW, I think the default pref for those is wrong. There is a patch up for review in bug 65794 on this (and I also noticed now that a similar UI-related patch had been denied review there some time ago). Personally, I'd prefer one of the solutions based on MIME types or individual pasting behavior proposed in that bug over a global preference. If such are implemented, mail.content_disposition_type certainly would have a lesser importance. On the other hand, a visible UI menu would provide a workaround for users affected by the current default, and may also serve as a "placeholder" for any additional UI to implement a more comprehensive solution.
(In reply to comment #4) > Are you talking about both preferences or just mail.content_disposition_type? > For mail.reply_quote_inline, it would be good to have this visible so that > people who want to use the feature to get back to the old behavior actually > find it at an intuitive place. The Attachments pane currently offers a lot of Both. It's not like there have been enormous demand for it - I recall only one or two people requesting it, therefore a hidden pref would seem fine. It's also *very* technical, no normal people would really know what to do with it. Adding UI just because there (currently) is some room for it is not a very good reason if it's the main/only reason. > > "When possible, ..." (or something) as it just applies to a few types. > > These are two different issues, one is how we are sending out the attachments > (strictly defined by that preference) and how the receiving client displays it. > If you prefer a more careful phrasing, I'd suggest "If supported, ..." to make > it more apparent that this is beyond the sender's control. Or maybe just list the types, "For text and html attachments...".
(In reply to comment #5) > Adding UI just because there (currently) is some room for it is not a very good reason > if it's the main/only reason. No, that's neither the main nor the only reason. It was motivated in the RFE for the backend, and IanN has recommended to look into the quote option for SeaMonkey's UI, so this was my main reason for filing this followup. As for "technical", that's a yes for the content disposition preference, but I'd see the "Quote attachments in replies" option as clearly non-technical, especially since the default behavior changes to "not quoted" with TB 3.0. > Or maybe just list the types, "For text and html attachments...". Which again may be tricky as it's probably not a good idea to preempt whatever is decided in bug 65794 in the end, and at the time of sending it is not known which attachment types the receiving client can and will render inline. Dan, did you have something specific in mind when suggesting this?
No need to preempt, as bug 65794 is only about the sending format.
Comment on attachment 329388 [details] [diff] [review] Proposed patch it's a bit debatable if this belongs in the attachments sheet, or the composition sheet, but I'll let Bryan weigh in on that. The code looks ok, thx for the patch!
It's probably somewhere inbetween, addressing the handling of attachments for outgoing messages, so it should fit for both. Before suggesting the Attachments pane/sheet, I also looked into putting those prefs into the Composition pane. I don't see any tab there where they would fit nicely, no space in the General tab, and the Addressing and Spelling tabs don't match topic-wise. Thus, moving them into the Composition would likely imply adding a fourth tab, certainly feasible but adding some more complexity.
Follow-up on comment #9 for a possible placement of these options in the Composition pref pane. There is now bug 448702 to remove the checkbox for quoted-printable encoding from the General tab, which would free up some space there. If the decision is to remove that checkbox and to not provide a UI for the content disposition here, the "Quote the contents of displayed inline attachments in replies" option could go into the General tab. On the other hand, if an additional tab is added to the Composition pane, it could accommodate all three of those preferences, which don't necessarily have to appear in the General tab. Thus, several options, waiting for Bryan's comments and suggestions on this.
Yeah, I don't think I like this as a pref. On outgoing messages deciding inline vs. attachment seems to be more like an action related to composition and not a general preference. When writing an HTML mail and using the "Insert Image" option a person assumes the image will show in the mail and we inline the attachment of the image. Otherwise a person could just attach the image as a file. I believe this separation of inline vs. attachment disposition makes the most sense. With non-html mail I don't see why we couldn't have an insert text file button for placing a text or html file inline. In the quoting inline attachments I can see how there might be a desire to have a preference like this; even though I suspect a large percentage of our users won't fully understand the option. By the way, what is the default here? Seems like it should be on by default. The Composition area would seem like a better fit for this option.
> (comment #11) When writing an HTML mail and using the "Insert Image" > option a person assumes the image will show in the mail and we inline > the attachment of the image. I think inserting an image into an HTML message shouldn't be affected by that preference (which is clearly "inline" in that case), this is more about the disposition of an attachment from a file. The discussion in bug 65794 about this preference includes some suggestions for intuitive ways how to determine the disposition when attaching a file. Again, I would have no problems to defer any solution for the disposition issue to that more comprehensive bug. > In the quoting inline attachments I can see how there might be a desire to have > a preference like this; ... By the way, what is the default here? Per bug 161775, it defaults to "false", thus attachments displayed inline are not quoted in replies (images as part of an HTML message body are still quoted regardless of that setting). This is different than the current behavior in the branch releases, which on the other hand was criticized. Thus, keeping the default of not quoting attachments while on the other hand providing an easy checkbox to revert to the prior behavior would make both sides happy.
I think we need to have a better understanding of what the use cases are here. Parity with SeaMonkey is non-goal, in my opinion. The mere existence of stuff in the backend and wire protocols is not in and of itself sufficient reason to spend UI space & complexity on it. What do people think the specific use cases are here? I'd be particularly interested in hearing what Eudora customers used this for, if it's known...
As summary from bug 384599, having the contents of attachments quoted in a reply to incoming messages is of interest whenever some sort of annotation or comments on those attachments is desired. Important use cases are review and ticketing systems (or a collection of jokes and cartoons, to name a more casual example) where inline commenting for an attachment is needed within the actual context of that attachment, similar to the ability of commenting on patches in bugzilla. In this way, the attachments become integral components of the message, even though they were sent as separate parts. Another example, when replying to a message which has a message/rfc822 attachment, it may be desirable to provide the forwarded message as part of the quote to be able to add inline replies. Again, the message attachment can be considered part of the forwarding message, even if forwarded as attachment. For content disposition of attachments in outgoing messages, it is similarly relevant to distinguish whether or not the attachment is considered part of the message body. Large data files which are text based should not be sent inline (true attachment), whereas a patch or ticket could be understood as part of the message and should be shown with it (important part of the message). I agree that a global preference is likely not the optimum solution here. I don't know how and in which contexts Eudora is handling this issue, thus it certainly would be interesting to compare.
I imagine Jeff fixed bug 161775 exactly because Eudora didn't use to quote inline attachments? A lot of people really wanted them not included, which is very understandable imo. Also looking outside the ASCII world, quoting the inline attachments won't work properly - just try to with a utf-8 text attachment... (that may be another bug though).
(In reply to comment #15) > I imagine Jeff fixed bug 161775 exactly because Eudora didn't use to quote > inline attachments? A lot of people really wanted them not included, which is > very understandable imo. Yes, but there are other use cases where quoting the contents of attachments is important, which is why we had bug 384599. Please keep in mind that this bug here is about whether or not this option should be made visible by a UI element and not about the preference itself. I'm fine with keeping it set to false by default, as this represents the setting that most seem to prefer. (In reply to comment #13) > I'd be particularly interested in hearing what Eudora customers used this for, > if it's known... I was under the impression that Dan was referring to the content-disposition setting rather than the quoting issue.
On another note: I filed this proposal before bug 448716 came up, which is suggesting a major overhaul of the preference panes. Thus, I'm wondering more generally whether any UI for the preferences discussed here should be part of that larger (but possibly mid- or long-term) effort, or could be decided on individually based on the current pane layout.
Created attachment 335186 [details] Composition pane Judging from the discussions in the previous comments, it appears that (a) the UI element for the quote preference is less disputed than the disposition preference, and (b) the Composition pane is considered more suitable than the Attachments pane. Thus, I'm posting a screen shot for an alternative to the original proposal, which would minimize the UI changes. This utilizes the space in the Composition pane freed up by bug 448702 to place the "Quote attachments in replies" checkbox there instead (comment #10), and the disposition handling would be deferred to the other bugs where it is the main topic. I'll post the patch for review if the decision is to proceed in this way.
Comment on attachment 329388 [details] [diff] [review] Proposed patch Ping for ui-review... Bryan, this has been up for review for several months now, and the tentative feature freeze for 3.0 is approaching for sure some time soon. Thus, it would be good to come to a decision on this patch. There are a couple of alternatives, being it in the Composition or Advanced preference panes, one of those prefs or both, so suggestions on how to proceed would be appreciated.
Comment on attachment 329388 [details] [diff] [review] Proposed patch Thanks for the ping, didn't mean to drag this out. I think this would be much better suited to Thunderbird as an extension instead of in the main prefs window. As an extension you could just turn this preference on or possibly have finer control on what accounts to turn the pref on for. I really should have submitted bug 464621 and leaned on it earlier so we had a chance of getting it into gecko with our release.
->WONTFIX per previous comment. (And i certainly agree.)
(In reply to comment #20) Too bad, but thanks anyway for getting to some conclusion. I figured from the comments here and in bug 448716 that this patch may not have much of a chance. I see your notion of keeping the main preferences "lean" but I also would be rather cautious with leaving too much functionality up to extensions. As said elsewhere already, users should find settings likely to be customized during the initial setup or frequently used (and especially given that the defaults behavior changed here between major versions) and may get annoyed if they are unable to access those with reasonable effort. As for mail.content_disposition_type, bug 452092 will hopefully lead to an intuitive solution to specify the outgoing attachment deposition.