49180 - multi-attachment download kill previous downloads

Status: VERIFIED WORKSFORME

(MailNews Core :: Networking, defect, P3)

Description

[Marc d'Entremont]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20000813
BuildID:    2000081308

When an email has multiple attachments and in process of downloading an
attachment from an IMAP account the downloading a second or more attachment will
stop the current download, i.e. only the final downloaded file will not be
corrupted, unless you wait until the previous download to finish.
Also, probably unrelated; the indicator showing whether the file has been
downloaded is not updated

Reproducible: Always
Steps to Reproduce:
1.from email with multiple attachments start download of an attachment
2 [details] [diff] [review].before completion of the download begin the download of an other attachment.
3.first file should be corrupted

Actual Results:

Expected Results:  A new process for each download that automatically terminates
on completion or a new process for download and a separate thread for each
download.

If the download does not complete reget from where the download left off would
be excellent.

Comment 1

[Gervase Markham [:gerv]]

Confirming on 20001020 Win95. This is serious! People often delete emails after 
grabbing the attachments without checking their integrity. This is a dataloss 
bug.

I know it's late, but rtm?

Gerv

Comment 2

[selmer (gone)]

Might consider an extremely small and safe patch, otherwise I think this should
be minus.

Comment 3

[Marc d'Entremont]

This may be a larger problem then originally thought.
When I download a *.tar.gz file the file seems to become corrupted.
This seems to happen when downloading though http (I haven't yet tried ftp).
To test I down load files with Mozilla and tired to unzip the file. gunzip did
not recognize the format. So I ssh-ed to the university and downloaded the file
with Netscape 4.61 then ftped that file to my machine where it was recognized by
gunzip.
This also happens when I download nightly builds from mozilla.org, I must ftp to
get a correct file.
This in being tested on RedHat Linux 6.1 with build 2000101921.

I am using Shaw cable in Victoria, B.C. as my ISP.

Comment 4

[Marc d'Entremont]

My last comment (i.e. corruption of *.tar.gz files) seems to be only on specific
servers. mozilla.org is one of those sites that I have a problem with, but I had
no problem when downloading a the Acrobat 4 reader in tar.gz form from adobe.com.

Do you think it could be to do with the browser mis-interpreting the gz file as
a compressed html file?

Comment 5

[Marc d'Entremont]

Sorry guys, please disregard my last two posts. My brain's been out to lunch.
The problem downloading tar.gz file can not be associated with the corruption
problem when downloading attachments.
It still is a problem though. I will check and make a new report if appropriate.

Comment 6

[Scott MacGregor]

not an rtm show stopper. 

Comment 7

[Gervase Markham [:gerv]]

<fume>.

Adding relnote keyword.

Gerv

Comment 8

[Akkana Peck]

Could this be related to the netlib problem causing data corruption in bug
54081?  That bug has a patch, might be worth trying the patch and seeing if it
helps here (or if something similar might help).

Sounds pretty severe -- users aren't going to trust our mailer if it corrupts
their mail upon saving.

Comment 9

[selmer (gone)]

What about putting up a busy cursor since the individual downloads appear to be
synchronous to the window?

Comment 10

[Gervase Markham [:gerv]]

Akkana: I can't try the patch, as I don't build Moz. As soon as that patch gets
checked into the branch and trunk, we can try and see. Absolutely.

Also, this is more serious than it first appears: any IMAP transaction, whether
it be requesting a new message body or another attachment to the same message,
will cause downloading to silently cease and the file to truncate.

Side note: is the test plan for this area of Mail/News on www.mozilla.org anywhere?

Gerv

Comment 11

[Hixie (not reading bugmail)]

Gerv: Can you write up the release note item please? I tried, but do not 
understand the bug well enough to do so.

Comment 12

[Gervase Markham [:gerv]]

Ian: The current situation (and I have no idea how this came to be the case, and 
wasn't noticed for so long) is that _any_ IMAP request triggered using the mail 
window while attachments are downloading will silently stop the download and 
truncate the file. The release note would therefore read something like:

"If you are downloading a MIME attachment, don't do anything in the mail window 
until it's finished. You can tell it's finished by the progress bar at the 
bottom, except when you've done Save All..., whereupon you have to wait for the 
progress bar to complete the same number of times as there are attachments. 
Failure to do this could result in silent data loss."

I hope that this will not remain the case by RTM :-) I'll write up a relnote as 
soon as someone decides what we are going to do to mitigate the above nightmare. 

Selmer's idea is looking more and more promising - I'm just worried people will 
think Mail has hung...

Gerv

Comment 13

[Karen Huang]

By using 10-23-09-MN6 build, I couldn't reproduce this problem.
What kind of the attachments and size are you using?
Also, my tests didn't cover this area. 
Peter, do your tests cover this area?

Comment 14

[Marc d'Entremont]

The files I used were mpg, and power point. Reasonably large files. I would
expect at least a meg each.

Comment 15

[Ben Bucksch (:BenB)]

How does this bug relate to inline display, e.g. a mail with 3 attached images?
I saw that Mozilla sometimes download them only halfly, some not at all.
However, I saw the same in 4.x.

Comment 16

[pmock]

I can reproduce this problem on today commercial win32 2000-102309-mn6 build.
 
Steps to reproduce problem:
0) From Communicator 4.7, send yourself a mail message with three attachment.
   I had two powerpoint attachment and one zip file.
1) Start Seamonkey
2) Open Mail
3) Select your mail message sent from 4.7
4) Click on attachment button
   You have three attachments
5) Select the first attachment
   The save as dialog appears
6) Select the save location to an empty directory (for easy viewing)

** The next few steps should be performed as fast as possible
   Use large attachment...

7) Save the first attachment
   The progress bar should indicate the attachment is being saved
8) Select the 2nd attachment and begin the save process before the first 
attachment is done.
9) Select the 3rd attachment and begin the save process before the 2nd 
attachment is done.

Look at the save attachment and compare the file size to the original 
attachment.  You should see one of the attachment is smaller / corrupted.

This scenario is covered under my attachment test spec.  It's the last test case 
which covers corner cases.  Normally, you expect end users to use the save all 
attachment options. 

http://www.mozilla.org/quality/mailnews/tests/sea-mn-attachment.html

Comment 17

[pmock]

Changing qa assign to myself.

Comment 18

[Karen Huang]

> I saw that Mozilla sometimes download them only halfly

I am seeing the same problem as Ben's mentioned, it seems that we have 
regression on bug 40703 (but bug 40703 is different as this bug) and there was 
existing bug which I logged bug 45720 for 8MB attachments problem before.

Comment 19

[fenella]

Assign it to myself.

Comment 20

[scottputterman]

This currently isn't planned for mozilla0.8.  I've changed the nomination to
mozilla0.9 so it gets properly triaged for the next milestone.

Comment 21

[Ben Bucksch (:BenB)]

IMO, we should leave those old nominations intact - they show "somebody thought,
it should have been fixed long ago". There's no easy way to query for them
otherwise. (Can't search for the bug activity history :-( .) If somebody
disagrees, please post to .webtools and cc me <[e-mail]>.

Comment 22

[fenella]

To Esther ..

Comment 23

[Ben Bucksch (:BenB)]

Mass-change: Do not remove nominations (even if Milestone passed). Readding
mozilla0.8 nomination.

Comment 24

[Gervase Markham [:gerv]]

mscott: ping! :-) I can't believe something this serious is still an issue six 
months on... Is the current Mail/News work going to fix this?

Gerv

Comment 25

[scottputterman]

Is this still happening?

Comment 26

[Andreas Premstaller]

Tested on W2K with build 2001080103:

When I download one attachment of a multiple-attachment mail from an IMAP-server
(UW-IMAP), then I cannot download a second attachment of the same message until
the first attachment is completely downloaded (shows busy cursor, nothing
happens on doubleclick). I can however change to another folder and display
messages, and even download the attachment of another message, without breaking
the first download. 

"Save all" sequentially downloads the attachments, no problem there. 

No dataloss observed, however it would be nice if I could start multiple
downloads from one message at the same time and then just have them go on in the
background.

Comment 27

[Gervase Markham [:gerv]]

This is no longer happening. The attachment download requests appear to be
queued, and the attachments are downloaded sequentially.

Gerv

Comment 28

[esther]

Using windows build 2001-080-28 and save as 5 attachments, from the same
message,  individually as previous save is going on saves all attachments OK. 
Verified as worksforme