416342 - download of attachments window shows that download does not progress

Status: VERIFIED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Fernando Piera]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008020708 Minefield/3.0b4pre
Build Identifier: version 3.0a1pre (2008020703)

downloads of attachments if done through the save as smll window using the left tocuh of the mouse get stuck and not progress and the download window shoes this.  Donwload done by punching on the atachment icon and asking to save in the openingg window progress perfectly.  This different of behavious occurs systematicaly since more than 10 days of nightly updates.

Reproducible: Always

Steps to Reproduce:
1.open window with secondary mouse touch on attachment icon
2.punt save as
3.download window opens and shows minimum progress.  download get stuck
Actual Results:  
download does not progress

Expected Results:  
download of attachment progresses and finishes in few seconds

download punching the attachment icon and opening the large window and asking to save the attachment works without problem

Comment 1

[Nomis101]

Same bug here with Thunderbird on OS X. If I try to download an attachement (e.g. 1,4 MB) the status bar goes to 1,4 from 2 MB and stop there. But the file is only 1,4 MB in size. So I have downloaded this file completely in all cases. 
This Bug is also mentioned in mozillazine forum: http://forums.mozillazine.org/viewtopic.php?p=3245753#3245753

Mac OS X 10.5.1, de, Thunderbird Version 3.0a1pre (2008020803)

Comment 2

[Joe Sabash [:JoeS1]]

Regression range:
OK= Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012703 Thunderbird/3.0a1pre ID:2008012703
 
Regressed= Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012803 Thunderbird/3.0a1pre ID:2008012803

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-27+03%3A00&maxdate=2008-01-28+03%3A00&cvsroot=%2Fcvsroot

Assuming TB uses the ff DM then Bug 405107 ?

Comment 3

[Ed Lee :Mardak]

So what's the two different ways to save here? There's a right click save as and a "large window" save?

Comment 4

[Fernando Piera]

with an attachment in an email that appears with an icon on the lower part of the email you can download it either with a right click on the mouse which shows a small window with open, save as, detach and delete options, if you use the save as for downloadiing, once determined the name of the file and the directory to put it, the downloading window opens and here are the problems as the process does not finishes.
The second method of downloading is punching on the icon and a larger window opens mentioning that you have chosen to open the attachment, then directly you can save it to the deault directory and this time the donwloading process works correctly. 

Comment 5

[Joe Sabash [:JoeS1]]

Some additional clues..DM seems to be over estimating the size of the file.
Take a look here: http://img262.imageshack.us/img262/7082/dmrl5.gif
The actual size of the attachment is 244.9 KB yet the DM thinks it is 337 KB

Comment 6

[Joe Sabash [:JoeS1]]

Further, 337 KB is the size of the complete message, not the size of the attachment part.

Comment 7

[Ed Lee :Mardak]

Any idea how thunderbird saves attachments? From the "wrong total size", I would assume webbrowserpersist..

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #7)
> Any idea how thunderbird saves attachments? From the "wrong total size", I
> would assume webbrowserpersist..

Dan should know

Comment 9

[Fernando Piera]

Even if the download window shows that the downloading process is not finished, it is not true, it has been finished correctly.

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #9)
> Even if the download window shows that the downloading process is not finished,
> it is not true, it has been finished correctly.

In that case, this sounds like bug 413200.

Comment 11

[Nomis101]

(In reply to comment #10)
> (In reply to comment #9)
> > Even if the download window shows that the downloading process is not finished,
> > it is not true, it has been finished correctly.
> 
> In that case, this sounds like bug 413200.
> 

I think this is a different bug.

Comment 12

[Joe Sabash [:JoeS1]]

(In reply to comment #10)
> (In reply to comment #9)
> > Even if the download window shows that the downloading process is not finished,
> > it is not true, it has been finished correctly.
> 
> In that case, this sounds like bug 413200.
> 
A fix for bug 413200 has been checked in and does resolve that bug.
However after that checkin, this bug symptoms remain.
Tested with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030318 Thunderbird/3.0a1pre ID:2008030318

Comment 13

[Fernando Piera]

When the download opens, using XP and nightly version mentioned in previous comment 12, it does not finish the downloading process, but if that process is stopped using the x small button and then realunched using the small button in the window, the downloading process finishes succesfully

Comment 14

[Ed Lee :Mardak]

Bug 418961 might fix this problem. From what I can tell without looking at mail code, the attachments are coming from a mail: uri type protocol which already has the file ready to download, and it goes through a separate code path that doesn't use STATE_IS_NEWTORK.

Comment 15

[Ed Lee :Mardak]

Or maybe it's this line that doesn't send STATE_IS_NETWORK.. I'll look into /mailnews a bit more for nsITransfer usages.

http://mxr.mozilla.org/seamonkey/source/mailnews/base/src/nsMessenger.cpp#2055

Is there a dev doc thing about using toolkit download manager and that it now expects STATE_IS_NETWORK?

Comment 16

[Ed Lee :Mardak]

Does this problem show up if you save the message itself as well? Not just attachments?

Comment 17

[Ed Lee :Mardak]

 231 // jefft - this is a rather obscured class serves for Save Message As File,
 232 // Save Message As Template, and Save Attachment to a file

Comment 18

[Joe Sabash [:JoeS1]]

(In reply to comment #16)
> Does this problem show up if you save the message itself as well? Not just
> attachments?
> 
All the other save functions seems to work normally.
Another oddity: If you have a jpeg attachment ans "view attachments inline" right clicking the displayed attachment calls DM and progresses normally. Thr right click context shows as "save image"
Right clicking on the attachment icon shows "save as" and does not terminate the DM window.

Comment 19

[Joe Sabash [:JoeS1]]

Checkin for bug 418961 had no effect on this bug. Symptoms persist in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030902 Thunderbird/3.0a1pre ID:2008030902

Comment 20

[Ed Lee :Mardak]

Attachment: v1

Thanks for keeping me updated Joe. Finally got around to grabbing mailnews source and compiling.

Adding the extra STATE_IS_NETWORK flag fixes it for me.

Comment 21

[Ed Lee :Mardak]

Checking in mailnews/base/src/nsMessenger.cpp;
/cvsroot/mozilla/mailnews/base/src/nsMessenger.cpp,v  <--  nsMessenger.cpp
new revision: 1.382; previous revision: 1.381
done

Comment 22

[Fernando Piera]

in windows XP with nightly version 3.0a1pre (2008030902)still the downloading process of "save as..." of attachments gets stuck and does no finishes.  It is necessary to stop the downloading pushing the x button and then pushing the restart button the downloading process finishes

Comment 23

[Joe Sabash [:JoeS1]]

(In reply to comment #22)
> in windows XP with nightly version 3.0a1pre (2008030902)still the downloading
> process of "save as..." of attachments gets stuck and does no finishes.  It is
> necessary to stop the downloading pushing the x button and then pushing the
> restart button the downloading process finishes
> 
Checkin was in this build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031002 Thunderbird/3.0a1pre ID:2008031002

Save as on a large jpeg works fine.
Thanks for the follow-through Edward.

Comment 24

[Ed Lee :Mardak]

Verified per comment #23.