Closed Bug 188344 Opened 22 years ago Closed 22 years ago

forward a email as a attchment will be failed to display correctly

Categories

(MailNews Core :: Composition, defect)

x86
Windows 2000
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: antonio.xu, Assigned: antonio.xu)

Details

Attachments

(1 file)

Build ID: Mozilla 1.3b(Trunk)
I found a serious problem when I open email which is a forwarding email. The 
probelm is the original email's attachment can't be displayed correctly.

Steps to Reproduce:

1. Send a email to yourself and attach a jpg file(any attachment).
2. Receive this email
3. Forward this message as attachment to yourself
4. Receive the forwarding email, and open it.
Expected Results:
jpg file should be displayed correctly
Actual Results:
You will see the attachment's source code of original email in mail window.

It is a regression
I have find a way to fix it, I will create a patch for this bug tomorrow. :-)
Assignee: ducarroz → antonio.xu
this fixed caused a regression.  see
http://bugzilla.mozilla.org/show_bug.cgi?id=188344
This bug is caused by patch of bug #161488, but if you enable ENABLE_SMIME when 
you build mozilla, this bug will not happen . When you try to forward a email 
to other guys, mozilla will parse this email, then add parsing result into a 
new email,finally sent it out. But if this email has been encrypted, mozilla 
must decrypted this email before add it into new email. So mime parser will 
judge whether we should decrypted this email automatically. but there have a 
problem, this part of code (judgement) was writed in #ifdef ENABLE_SMIME. So if 
we didn't enable ENABLE_SMIME when we build mozilla, mozilla will think every 
attachment should be decrypted due to the judgement didn't work. Then this bug 
will happen. please see the code below

(code in mimemsg.cpp)
#ifdef ENABLE_SMIME
    /* If this message has a body which is encrypted and we're going to
       decrypt it (whithout converting it to HTML, since decrypt_p and
       write_html_p are never true at the same time)
    */
    if (obj->output_p &&
        obj->options &&
        obj->options->decrypt_p &&
        !mime_crypto_object_p (msg->hdrs, PR_FALSE))
    {
      /* The body of this message is not an encrypted object, so we need
         to turn off the decrypt_p flag (to prevent us from s#$%ing the
         body of the internal object up into one.) In this case,
         our output will end up being identical to our input.
      */
      obj->options->decrypt_p = PR_FALSE;
    }
#endif /* ENABLE_SMIME */

But you know mozilla release build will include the building option"--enable-
crypto", this option will enable ENABLE_SMIME. So if you download the binary 
build from mozilla, you couldn't found this problem. I don't know whether I 
should add the patch for this bug. So could somebody give me some advice? Thank 
you!
Move the #ifdef and that should fix your problem:

    /* If this message has a body which is encrypted and we're going to
       decrypt it (whithout converting it to HTML, since decrypt_p and
       write_html_p are never true at the same time)
    */
    if (obj->output_p &&
        obj->options &&
        obj->options->decrypt_p
#ifdef ENABLE_SMIME
       && !mime_crypto_object_p (msg->hdrs, PR_FALSE)
#endif /* ENABLE_SMIME */
       )
    {
      /* The body of this message is not an encrypted object, so we need
         to turn off the decrypt_p flag (to prevent us from s#$%ing the
         body of the internal object up into one.) In this case,
         our output will end up being identical to our input.
      */
      obj->options->decrypt_p = PR_FALSE;
    }

Creating patch according to Jean-Francois Ducarroz's comment. Jean-Francois
Ducarroz, Could you r=? my patch?
Attachment #112017 - Flags: review?(ducarroz)
Comment on attachment 112017 [details] [diff] [review]
patch version 1.0

R=ducarroz
Attachment #112017 - Flags: review?(ducarroz) → review+
Comment on attachment 112017 [details] [diff] [review]
patch version 1.0

Hi Bienvenu, could you sr=? my patch. Thanks.
Attachment #112017 - Flags: superreview?(bienvenu)
Comment on attachment 112017 [details] [diff] [review]
patch version 1.0

sr=bienvenu
Attachment #112017 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 112017 [details] [diff] [review]
patch version 1.0

Asa ,could you give me your approve? Thanks.
Attachment #112017 - Flags: approval1.3b?
Comment on attachment 112017 [details] [diff] [review]
patch version 1.0

a=asa (on behalf of drivers) for checkin to 1.3beta
Attachment #112017 - Flags: approval1.3b? → approval1.3b+
fix checked in trunk
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: