Using 12-08-08m12 commercial builds The prefs UI is displaying "Inline" for a migrated value of 0 (Attachment) in pref mail.forward_message_mode. If you change the value through the UI to Attachment it does properly write the value 0 to the prefs.js file. If you change the value through the UI to Inline the value is properly written as 2 to the prefs.js file. 1. Open 4.x. Edit|Preferences|Mail&Newsgroups|Messages. Set the value in the dropdown to Attachment for "By default, forward messages:" Confirm OK. Exit 4.x 2. Check the value of the 4.x prefs.js file for mail.forward_message_mode and see that it is 0. 3. Migrate the account to 5.0 and open messenger. Check the 5.0 prefs.js file and see the value 0 has been properly migrated. 4. Edit|Preferences|Mail&Newsgroups|Messages. Note the value displayed in the dropdown for forward_message_mode is "Inline". Expected result: for migrated value 0/Attachment, the 5.0 prefs UI should display selection as Attachment. For migrated values of 1 or 2, the 5.0 Prefs UI should display "Inline" (we've taken away forward as quoted for 5.0, ref bug #15556)

accept

fixed.

Reopening: Using jan04 commercial builds: 1. Good/fixed: migrated 0/Attachment now displays in 5.0 UI as "attachment" 2. Good/stayed same: migrated 2/Inline displays in 5.0 UI as "inline" 2. Bad/broken: migrated 1/Quoted now displays in 5.0 UI as "attachment" when it should display as "inline". We fixed the previous incorrect display and created a new one.

see related bugs #15556 and #22990 I need to see what the spec says we do for forward quoted (pref value == 1) and what the default value is (forward as attachment or forward as inline?) then, I'll sort out which bug to fix, and which to mark invalid.

moving to m14.

marking p2

Seems good enough for B1. The default value should be forward as attachment.

Mass moving M16 to M17 - look for nsbeta2 before anything else.

Bringing this up again because the current jun01 revision of the mail prefs spec shows Inline as default value for this pref. (I know this bug covers some other issues as well.) If we truly decide to go with attachment as default value (as phil mentioned in jan28 comments), we need to coordinate with jglick to get the spec updated. ref mail prefs spec, composition panel: http://gooey/client/5.0/specs/mail/Prefs/Preferences.html#Composing

Default pref for forward should be "Inline". When novice and average users forward a message, they expect to SEE the message being forwarded in the message body. We are currently observing this in the multiple mail accounts usability testing. Novice and average users don't change the prefs, so we should give them the default they expect. More knowledgeable users will know to go to prefs to change this if they want the default to forward as "Attachment". Also, "Quoted" is shown as a Forward default option in the Prefs. I thought Forward Quoted was out for Netscape 6? Nominate as nsbeta3.

In 4.7, forward as attachment and forward inline both forward any attachments to the original message. Forward quoted does not forward the attachment. In Seamonkey, forward as attachment forwards any attachments to the original message, but forward inline does not. I agree with Jennifer that novice users expect to see the text of the message they are forwarding. I also think that most users expect that when they forward a message that has an attachment, the attachment is also forwarded. Therefore, I would advocate the default behavior be forward inline and include any attachments from the original message.

Yes, forward as "Qutoed" should be out. And forward inline should always includes all the attachments from the original message. Foward inline does include all the attachements on the current implementation, isn't it?

If you want to see the attachment, improve the composer, like showing attachments inline in an attachment pane. Forward Inline has the same weaknesses like Outlook's quoting-style (blurrs authorship).

ccing endico

If newbies have trouble with the ui for forwarding as attachment then the UI should be changed, not the default attachment mechanism. If the message compose window were changed so that it previewed attachments the same way they appear in the message pane that would make it easier for people to understand. Forwarding messages as mime attachments is the right thing to do because the resulting email is parsable. The content of the message can be seperated from the mail headers, even after multiple forwards. If some of the forwarders forwarded as inline then the message becomes gobbeldygook and is impossible for the mailer to parse and hard for users to read. My mail tends to contain lots of messages that have been forwarded multiple times. If the default forwarding mechanism is changed this will have a big effect on the mail I recieve. I think people will be a lot more confused by recieving forwarded messages containing gobbeldygook than by the status quo of not seeing a preview of attachments. Let the default forwarding option stay the same and fix the UI in the compose window later. If you insist on changing this, please only do this to the netscape tree, not to mozilla. thanks see bug 44135

This needs to conduct an user study. Not everyone has the same view as you do. I don't quiet agree with your arguments. Personally, I prefer forwand as inline.

One more note, our implementation of forward as inline is different from "Outlook Express". We include all attachments and they don't.

Jeff: In response to your question above - I forwarded inline a message with an attachment and could not retrieve the attachment. I then viewed the page source for the message, and could not find the attachment part. Also, I believe Jennifer has already done the testing and determined that our users are confused by the default 4.x forward as attachment behavior.

> Jeff: In response to your question above - I forwarded inline a message with an > attachment and could not retrieve the attachment. I then viewed the page source > for the message, and could not find the attachment part. If the original message did have the attachment and for some reason that forwarding the message inline did not carry over the attachment then some thing is broken badly. If the original message falsely advertising that it has an attachment then some thing is broken too. There are some cases that I can think of may cause the problem. For example, IMAP mime part on demand which did not download the attachment until you ask for it. Another example, Pop3 partial message download may have partially downloaded an attachment.

It's not just a user study. There are important internet standards that forward inline just walks all over and busts. Dawn is right. Don't do this to the mozilla tree. If you must do it, do it to the Netscape tree so that the rest of us can disown you.

> Also, I believe Jennifer has already done the testing and determined that our > users are confused by the default 4.x forward as attachment behavior. This testing is based on the current attachment UI, so the results are invalid, if we change the UI. > If you must do it, do it to > the Netscape tree so that the rest of us can disown you. This doesn't really help, if I, as a Mozilla user, get bad msgs from Netscape users.

Adding putterman to cc list.

We're leaning towards making forward inline as the default. Before we do, could those of you arguing against it clarify some things? What "gobbeldygook" are you referring to? Could someone forward me a message that would show me this? I've tried forwarding combinations of inline and attachment and the difference isn't apparent to me. And more importantly, what important internet standards does forward inline just walk all over and bust?

It breaks MIME. See http://RF.Cx/rfc1521.html, section 7.3. I will try to look for other references. You must NOT assume that the person reading the mail is going to be using Mozilla-based software to read it! Other mail readers may have spiffy features to do things with forwarded messages; these features will only work if said messages are included as standard MIME attachments. For example, see http://RF.Cx/rfc2157.html. This defines interoperability between X.400 mail and MIME mail. In the introduction, it says This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. Well, you're going to break anyone who uses X.400-based email, because you're not using the MIME standard.

- per mail triage

sorry for the extra email. Removing mail2 keyword.

clearing milestone, m17 and m18 are meaningless now. these need to be triages along with the rest.

giving all my migration bugs to racham.

I'm going to make this a duplicate of the newer bug about this: 74072 *** This bug has been marked as a duplicate of 74072 ***

.