User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20120205 Firefox/9.0.1 SeaMonkey/2.6.1 Build ID: 20120205035916 Steps to reproduce: Per request from Wayne Mery (:wsmwk) I am opening a new bug report for the still existing issue from bug #390136. Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20120128 Firefox/9.0.1 SeaMonkey/2.6.1 I do not think it has to do with emails arriving in the background in my Inboxes via POP3 while I have been composing an email some longer while. I bet I get it because I have now lousy connection over 3G UMTS modem. POP3 fetch interval is 10 min from two different servers (one is tunneled 127.0.0.1:110, other is gmail.com via 995 SSL/TLS). Sending is via SMTP via openvpn connection to a qmail-based smtp server on port 25 (no SSL/TLS). Just for testing I composed a 5MB large email and sent to myself over the slow line and got it reproduced: The message subject was "test" and it contained almost 5MB of attachments. First I saw the Sending message window with percenatges raising up. Then, I saw briefly a "Message sent ..." window and then another window afterwards popped up: Title: Sending messages - test Status: Copy complete. Progress: a blue bar moving from the left to the right all the time Only "Cancel" button offered and the window stayed until I really clicked that button. The mail did end up in my Sent folder, has 4.9MB, and later on was received via gmail.com in my Inbox. No new messages arrived meanwhile but I did manually ask mailer to check both POP3 servers: gmail.com said "No new messages" while the other via OpenVPN did not answer, probably because I was just sending the message out over the same OpenVPN connection so it did not contact POP3 port of the overloaded VPN connection. After the message was sent and I pressed the Cancel button, I could re-check the POP3 server over the OpenVPN connection and it said "No new messages" (merely I want to say the OpenVPN connection did not die or did no re-establish - I even checked syslogs for messages in case the VPN would have broken for a while). I do not know but maybe it has to do with some buffers on the network side? OpenVPN eats the data into a buffer and mailer probably think the data was already snet (a long while I see that 100% were sent). However, they were probably not sent yet physically. Could that fool seamonkey mailer?

I'm pretty sure these hanging windows are still happening in SM 2.7. I'm running POP3 and IMAP and have also seen the hanging window for NNTP. I'll be going to 2.8b1 shortly, so will see if it still happens.

I have note this hanging "Copy complete" windows in SM 2.8, not sure if it was on my Win7 or Linux set-ups, may have been both. Aren't intermittent faults a bummer??

I have exactly the same problem for years .... POP3 account, big attachment, the mail was written to the sent folder. Pop-up window as: Status: Copy complete. Progress: a blue bar moving from the left to the right all the time Win7 pro SP1 and Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8 Due to the fact that this issue is reproductible ... could someone take it and correct this bug ?

I had a very similar problem on WIN for a while, reason was unwanted activity of a disabled Fortinet Antivius Program (Part of a VPN client package). Unistall and installation of a naked VPN client without Antivirus solved the problem. @Reporter: Still a problem for you?

It's a long time that i did not experience this problem. Perhaps solved by a SM version greater than 2.8

No response, nor reproduced for a long time, so I close this one for now. @Reporter: Please feel free to reopen this Bug if the problem reappears with a current SeaMonkey version and a current OS and if you can contribute a step by step instruction due to <https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines> (containing every key press and every mouse click) how to reproduce the problem reliably.

Hi Rainer, I haven't seen the "copy complete" issue either, had lastly seamonkey-2.32. However, it seems to me it got replaced by an issue that mailer complains the connection to SMTP server timed out. I think the story behind is, that on my tunnelled SMTP connection seamonkey pushing 5MB email into the buffer from say 80%, then the percentages "sent" increase very slowly (indeed, I have 2kB upload speed on the GPRS). The percentage line mostly gets to 100% but I am sure that actually maybe just 20% of real data were transferred. In principle seamonkey should now wait for some return value from the network stack confirming the SSL tunnel (with compression enabled, btw) has emptied. It evidently does not and maybe after 60sec it bails out with the message I already mentioned above ... something like "The connection to the SMTP server timed out". How to reproduce? Configure your SMTP settings to use an ssh-tunnelled connection, enable compression in /etc/ssh_config o on the commandline, send a 5-10MB email and force a slow speed on your real ethernet connection or use a 3G modem from your cellar.