Closed Bug 22034 Opened 25 years ago Closed 23 years ago

Loading IMAP message attachment twice?

Categories

(MailNews Core :: Networking, defect, P3)

Product:
MailNews Core
Component:
Networking
Platform:
x86
Other
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 93208
Milestone:
Future

People

(Reporter: kinmoz, Assigned: mscott)

References

Details

(Keywords: perf)

Attachments

(1 file)

Message for test case.
116.18 KB, text/plain
Details 
I'm using my 12/17/1999 debug build from 6am in the morning.

When I first click on the message, attatched to this bug, mail takes a while to
display the text of the message, as if it is downloading the entire message with
the attatchment.

When this initial download is complete, it displays the text of the message with
a divider, then pauses for about 15-30 seconds and then starts downloading
something again, which I assume is the image for display.

Is it really loading the image attatchment twice? Why the 15-30 second delay?
Attached file Message for test case. — 

    
  
Target Milestone: M14

    
    

    
  
Dup of bug 21728?

    
  
Status: NEW → ASSIGNED

    
    

    
  
So I have to be honest, I really didn't believe this bug when I first saw it.
=)But I started looking at it today and I am seeing something strange.

Here's what I see when I view Kin's attached message.
1) Click on the message. We run a mailbox url which represents the message. (Url1)
2) Mime gets the message and converts it to html. In the process it detects that
there is a inline attachment. It inserts a img url for fetching this inline
attachment which is something of the form: url1&part=1.2. This url is inserted
into the html document. Everything is good.
3) layout encounters the image url and passes it off to the image library. The
image library runs the url to fetch the image.  So I see the mailbox protocol
load this url (this is the 2nd url load).

Now we should be done with two url loads and everyone is happy. This is the way
it's supposed to work anyway.

4) But I see a 3rd url load. The image library asks for the image AGAIN. So it
runs the url twice.

I thought this was really strange. Maybe the image library starts loading the
image the first time to determine the image size, then aborts and reloads it again?

I'm confused. Adding rhp to the cc list as well in case he has any insight.

    
    

    
  
Sorry...don't know why I would get the reload again.

- rhp

    
    

    
  
Moving my remaining M14 bugs to M15 which is the next targeted milestone.

Target Milestone: M14 → M15

    
    

    
  
triaging since M15 is tonight. Not an M15 stoppper.

Target Milestone: M15 → M17

    
    

    
  
marking perf and nsbeta3.  moving to M18.
Keywords: nsbeta3, 
          
            perf
Target Milestone: M17 → M18

    
    

    
  
Is this still happening?  We'd like to know if it's happening and how likely
this is to occur before making an nsbeta3 decision.  If it's not a common case
then wep probably won't take it.

    
    

    
  
Putting [B3 Need Info] and generating more email....
Whiteboard: [B3 Need Info]

    
  
Keywords: mail2

    
    

    
  
is this a dup of 2731 and is this still happening?
QA Contact: lchiang → huang

    
    

    
  
There was sending problem for the attached file for last Friday's build
08-13-09-M18 build is not good, still wait for today's build --  I will try on 
today's build later. But, this looks similar to bug 2731.


    
    

    
  
*** Bug 2731 has been marked as a duplicate of this bug. ***

    
    

    
  
+, P2 per mail triage
Priority: P3 → P2
Whiteboard: [B3 Need Info] → [nsbeta3+]

    
  
Summary: Loading IMAP message attatchment twice? → Loading IMAP message attachment twice?

    
    

    
  
*** Bug 48585 has been marked as a duplicate of this bug. ***

    
    

    
  
gayatri kindly volunteered to help me out with this bug. 

    
    

    
  
per mail triage, reassign to gayatri
Assignee: mscott → gayatrib
Status: ASSIGNED → NEW

    
    

    
  
PDT thinks this is a P3, and only that high because of web mail
Priority: P2 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP3]

    
    

    
  
nsbeta3-
Whiteboard: [nsbeta3+][PDTP3] → [nsbeta3-][PDTP3][cut 9/11]
Target Milestone: M18 → Future

    
    

    
  
sorry for the extra email. Removing mail2 keyword.
Keywords: mail2

    
    

    
  
In my case, the IMAP server is M$ Exchange Server, and the mail sent to me was
sent using MS Outlook. The mail has 4 attachments, and no images appear on the
mail that indicates there is an attachment.

However, I can do "File -> Attachments ->" and I see all the attachments there,
marked "(Not downlaoded)". Each of my attachmnent is at least 700KB.

When I download one attachment, it appears mozilla is actually trying to
download ALL attachments, but only saving to disk the attachment that I requested.

The reason I said that are:

1) Using ethereal, I can see the IMAP responses containing text from OTHER
attachments that I did not request to download.

2) The file size appears to have completed download, but mozilla still has
"Downlaoding message" on the message bar below.

I am voting for this bug.


    
    

    
  
I forgot to mention I am using M18 on Linux 2.2.17, glibc-2.1.3 if that matters.


    
    

    
  
->mscott
Assignee: gayatrib → mscott

    
    

    
  
Removing PDT grafitti.
Whiteboard: [nsbeta3-][PDTP3][cut 9/11]

    
    

    
  
I'm pretty sure this is a dupe of a bug that is already fixed. Could you retest?

    
    

    
  
Yes, I think it could be a dup of fixed bug 93208.


    
    

    
  

*** This bug has been marked as a duplicate of 93208 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE

    
    

    
  
Verified as dup.
Status: RESOLVED → VERIFIED
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: