80347 - .doc attachment open as garbage if there is a supported attachment with it

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P2)

Description

[esther]

Using build 2001-05-11 on windows, if you send a message with a .doc file 
attached and anther inline supported attachment (.gif or jpg) the .doc file will 
open up and display garbage.  If the .doc file is the only file it opens OK.  
Not sure if this bug is related to bug 80332. 

1. Send yourself a message with a .doc file
2. Open the messge and open the attachment  = .doc file displays ok
3. Sent yourself a message with the same .doc file and a .jpg or .gif file
4. Open the message and opne the .doc attachment  =  .doc file opens and 
displays garbage.  

We had a bug similiar to this that was fixed and verified but in that one the 
.doc file always opened displaying garbage.

Comment 1

[esther]

fyi...Old bug for word attachments being corrupt is 73093, which was fixed and 
verified.

Comment 2

[esther]

marking nsbeta1+, attachments need to be displayed correctly.   Also note: the 
.jpg and .gif files don't display when opend in a browser window with this 
mixture of attachments  

Comment 3

[esther]

.

Comment 4

[scottputterman]

marking nsbeta1+ and moving to 0.9.2.  If somehow there's time in 0.9.1, this
sounds like a good one to fix.

Comment 5

[Scott MacGregor]

Attachment: a non acceptable hack that fixes the problem

Comment 6

[Scott MacGregor]

I've posted a patch which shows why we can't open the doc attachment if there is
an inlined attachment with the message. This patch can't be checked in, it's
wrong but it demonstrates what is going on.  I need to sit down with David
tomorrow to learn more about our imap body shell structure.

David, if I send myself a message with a .doc and a .jpeg (small jpeg), we
initially generate a body structure for the message. The jpeg gets a body part
#. In the imap log, I can then see us fetch just the image (since it's inline).
However, after fetching the image we then end up fetching the entire message and
extracting the image. That's because in ProcessSelectedStateURL we explicitly
say, if the url is of  type ?part= then don't use our body structure. (around
line 1840). So we fall back to fetching the entire message by chunks. 

If I force us to use the body structure we still fetch the image again (which we
shouldn't since the log shows me that we already fetched the image part) but at
least we don't fetch the entire message. 

This hacky little patch show how removing the constraint of not using the body
shell if the url contains ?part= allows things to start working. but there's
still an extra fetch of the image.

Maybe we can sit down together tomorrow and look at this. 

Comment 7

[David :Bienvenu]

Scott, we should have hit the code above, around line 1785:

            // A single message ID

            // First, let's see if we're requesting a specific MIME part
            char *imappart = nsnull;
            m_runningUrl->GetImapPartToFetch(&imappart);
            if (imappart)

Is it possible GetImappartToFetch isn't returning the part?

Comment 8

[Scott MacGregor]

Hey David, GetImappartToFetch only works for =section and ?section=. The url we
are getting is a ?part=. Don't ask me what the difference is =). But
GetImapPartToFetch ignores part= stuff. I'll try to tweak it to make it work for
part= too and see what I get.

Comment 9

[Scott MacGregor]

Attachment: possible fix

Comment 10

[Scott MacGregor]

I wonder if this is considered a beta stopper or not? cc'ing putterman

Comment 11

[scottputterman]

This would be great to fix for beta if you feel confident about your patch.  

Comment 12

[scottputterman]

adding PDT+.  please check in to the trunk as soon as possible.

Comment 13

[David :Bienvenu]

r/sr = bienvenu - I found my test messages folder - do you want me to
send/forward them to you or try them myself? They mostly have embedded images
but there are a few other kinds of messages.

Comment 14

[Scott MacGregor]

yeah that'd be great if you could send them to me. thanks david. 

Comment 15

[Navin Gupta]

r=naving

Comment 16

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 17

[Scott MacGregor]

fix checked in.

Comment 18

[esther]

Using build 2001-06-29 on win, mac and linux this is fixed. verified.