423761 - Sending of large attachments causes temporary freeze and chopiness

Status: RESOLVED INCOMPLETE

(Thunderbird :: Message Compose Window, defect)

Description

[Brent Davidson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: version 2.0.0.12 (20080213)

When sending an e-mail containing an attachment that is greater than a few megs or an attachment stored on a network drive the "Sending" progress indicator seizes focus, mouse movement becomes extremely choppy and switching to another application or another application is virtually impossible until the send operation has completed.

Reproducible: Always

Steps to Reproduce:
1.  Compose new e-mail
2.  Attach a large attachment, preferably on a network drive for best example
3.  Click "Send"
4. Try to move the mouse or switch to another application


Expected Results:  
Sending should somehow be relegated to a background task so that the user can continue working while the large attachment is sending.

Comment 1

[ovidiu]

possible similar to bug 389132, if temp files issue the same

Comment 2

[WADA:World Anti-bad-Duping Agency]

"Attaching data" process(read attachment data and format it as "mail data" such as base64) is executed upon first event of (a) Auto-save, (b) Save as Draft, (c) Send/Send Later. It'll take at least same time as (2) in below.
And, when "Send", time to take send == (2) + "send mail(pass data to SMTP server)" + (3).

How long will following tasks take in your environment?
 (0) Auto-save=Off (to exclude affect by Auto-save)
 (1) "Save As Draft" (written in "Drafts" you specified)
 (2) "Send Later" (written in "Unsent Messages" of "Local Folders")
 (3) Copy mail data of (2) to your "Sent" folder.

Comment 3

[Brent Davidson]

Auto-save doesn't make much difference, if any.  

In any of the following cases, there will be a slight pause with length depending on the size of the file while the file is apparently being retrieved from wherever it's store.  If the file is on the local hard drive the pause is barely noticeable.  If the file happens to be around a couple of megs, resides on one of our remote network servers, and has to be retrieved over the VPN then the delay can be as much as 10 to 15 minutes during which time there is a small box with a progress bar on the screen which apparently seizes focus and holds it until the file is retrieved preventing access to any other programs.

Comment 4

[Wayne Mery (:wsmwk)]

when this happens, it is with low cpu?

Comment 5

[Brent Davidson]

Yes.  CPU usage stays minimal.  It's just the fact that it won't release focus that keeps you from doing any further work.

Comment 6

[Wayne Mery (:wsmwk)]

some points for you to provide feedback on
a) what type of network connection? network card, wireless?
b) does focus issue/usability improve if you set mailnews.show_send_progress to true?
(go to tools>options>advanced>general>advanced configuration)
c) is it any better if you use current trunk build (thunderbird 3 beta)
  ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-trunk/
  (backup your profile first)

offhand, your statement of "mouse movement becomes extremely choppy and switching to another application or another application is virtually impossible until the send operation has completed" makes me think it is at least partly not thunderbird's fault - i.e. hardware/network related

Comment 7

[Wayne Mery (:wsmwk)]

=> incomplete - no response to comment 6

Comment 8

[Brent Davidson]

a) Network connection is a VPN that is run over 5Mbps DSL.  All internal machines are on 100Mbps lan.  Hardware is varied over about 50 different computers of probably 10 makes and models at 6 different offices All experience the same issues.  But it only occurs when attaching large files from a remote office.


b&c)  Will have to test these to see if there is any difference.

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #3)
> If the file happens to be around a couple of megs, resides on one of our remote network servers,
> and has to be retrieved over the VPN then the delay can be as much as 10 to 15 minutes
> during which time there is a small box with a progress bar on the screen
> which apparently seizes focus and holds it until the file is retrieved preventing access to any other programs.

Call the big file on your remote server over VPN "\\servername\sharename\subdirname\filename.ext".
How long does next commands take in your environment?
At Command Prompt:
  NET VIEW \\servername
  DIR \\servername\sharename\subdirname
  COPY \\servername\sharename\subdirname\filename.ext C:\WORKDIR\filename.ext.

Comment 10

[Brent Davidson]

There is definitely a direct correlation between the time it takes to copy a file and the time it takes to send a message, the difference is that the machine is still usable when copying a file.

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to comment #10)
> There is definitely a direct correlation between the time it takes to copy a
> file and the time it takes to send a message, the difference is that the
> machine is still usable when copying a file.

Brent, can you quantify comment 9 and 10, the send time and cite file size used so others can attempt replicate

Comment 12

[Joshua Cranmer [:jcranmer]]

RESOLVED INCOMPLETE due to lack of response to last question. If you feel this change was made in error, please respond with your reasons why.