Closed Bug 200056 Opened 23 years ago Closed 16 years ago

Copying of composed mail to sent folder fails

Categories

(MailNews Core :: Networking, defect)

Product:
MailNews Core
Component:
Networking
Platform:
DEC
OpenVMS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: Malmberg, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (X11; U; OpenVMS COMPAQ_AlphaServer_DS10_466_MHz; en-US; rv:1.3) Gecko/20030313 Build Identifier: Mozilla/5.0 (X11; U; OpenVMS COMPAQ_AlphaServer_DS10_466_MHz; en-US; rv:1.3) Gecko/20030313 After Mozilla has been running a while, after a message is successfully sent, it does not get copied to the sent folder. Reproducible: Always Steps to Reproduce: 1.Start up Mozilla 2.Use the cut and paste interface to report spam to spamcop.net 3.Send the spam to uce@ftc.gov Actual Results: After a number of messages are successfully sent and copied to the sent folder, messages are not able to be copied to the sent folder anymore. When the symptoms start, deleting the original message that is being forwarded to uce@ftc.gov will allow the message to be successfully copied to the sent folder, but eventually this stops working too. Expected Results: The message should be able to be copied to the sent folder. Mozilla 1.3 Mozilla/5.0 (X11; U; OpenVMS COMPAQ_AlphaServer_DS10_466_MHz; en-US; rv:1.3) Gecko/20030313 The sent folder is local to this system, so it should not take significant resources to copy the message to it.
Is the mail account itself POP3 or IMAP? Do you see any error messages or does it fail to copy silently?
Do either bug 197102 or bug 191398 sound the same?
197102 indicates that additional error messages about connection problems with the mail server are present. I do not see any, and there is no indications of problems with the connections to the mail server. So this is not as good of a fit. 191398 is related except that it only starts occuring after a number of e-mails have been sent. Also this problem occurs with both POP3 and IMAP/SSL e-mail, and news servers. So it is not related to a specific network protocol, and when it happens, both news servers, and both e-mail servers are equally affected. I suspect that using the view source for spam, select all, copy, and then paste into the spamcop.net web form is aggravating the condition, but have no proof of that. 191398 has been shutdown as a duplicate of 89285, and also references bug 123063 89285 is the closest match, but is referencing many symptoms that I do not see, it looks like a couple of similar bugs are merged in on it. This is something that has been reproducable usually in a few hours of operation of Mozilla mail/news, so if some additional verbose diagnostics can be enabled, we can probably quickly find out what the real problem is.
Do you get any error messages? Is the mail actually sent?
The e-mail or news posting is always sent. Either the mail window stays up for ever trying to copy to the sent folder, or a window pops up saying that the message was sent, but was unable to copy into the sent folder. When this happens, you also can not save the message anywhere else, but you can usually send copies of it to other e-mail addresses. There are no messages on the terminal session when this happens. Restarting MOZILLA is the only cure that I have found to prevent this. Expanding the pagefile quota to make JAVA happy has also delayed how long it takes for this problem to show up.
This may be related to bug 89285
You're right. It does sounds very much like bug 89285. But I'm not convinced it is, not yet. Marking this as "depends on" bug 89285. Then was once 89285 is fixed we can determine if this problem is the same and at that point dupe it if need be.
Status: UNCONFIRMED → NEW
Depends on: 89285
Ever confirmed: true
It appears to me that this bug may be at the root of the other bug, but as the network is not involved it could be easier to debug. It only takes a few days usually for the symptoms to show up here, so if there is some tracing or debugging that can be turned on, I should be able to provide some better information.
John, I'm not sure what tracing you can turn on that will be useful. There's tracing inside the POP3 and IMAP protocol handlers that you could enable, but since you say the message is always sent (its just the local copy that fails) I'm not sure that this would add any value. But in case you want to try it: $ define NSPR_LOG_MODULES "POP3:5" $ define NSPR_LOG_FILE TT: ! or some file $ @mozilla To trace the IMAP protocol stuff just use: $ define NSPR_LOG_MODULES "IMAP:5" And to trace both: $ define NSPR_LOG_MODULES "POP3:5,IMAP:5" Since you said the increasing pagefile quota seemed to increase the amount of time before you saw the problem, it could well be a resource/memory leak of some sort. Could you check the VM size from time to time, to see if it does look like there's a leak? And when the problem does occur, see if you're at (or near) your page file quota?
Any more news on this one, John?
No changes. Increasing the account quotas has extended the amount of time before the problem shows up, and typically now the browser crashes for a different quota exceeded or access violation before it shows up. I have not seen any followups on my posting on the related bug 89285.
I have experienced this bug under both FreeBSD 4.8 with Mozilla 1.4-1.6 and Windows XP with Mozilla 1.6. I only use the mail aspect. All my accounts are POP3 at the moment. My current Build I'm using on FreeBSD is: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040119 (Mozilla 1.6 release)
An update with Mozilla 1.5b. The behavior has changed. Now when the dialog box pops up about the failure to copy the mail to the sent folder, Mozilla crashes with an access violation. Most of the time, Mozilla either crashes on me from this bug or hangs from bug 216288, so my guess is that there is a common resource leak.
The crash I am seeing is marked fixed with bug 221633.
I see this bug also, and complained about it years ago. I am on build 2004052909 on XP. The account is IMAP, but the sent mail folder is local. One cannot even cancel the send and save them to the drafts folder because Mozilla says the window is locked. And Mozilla claims the message was not sent when I cancel out of the window, even though I think this is not the case. The only fix for me is to close Mozilla, so I think this bug needs a higher severity.
This raised its ugly head again today. My IMAP mail server was having problems. trying to delete an IMAP message failed. Then I switched to try and send a mail message with my other POP account and the copying to tthe local sent folder failed. Multiple times. In addition, part of Mozilla seemed to be "stuck" because I had to kill it in the task manager to get it to start up again. I am on build 2004091906. This problem needs to have a higher profile. It has been here for years!
This still happens a lot. One issue that seems to cause it is when the mail session starts while I have a VPN connected. If the VPN disconnects, the copying to the sent mail folder (A LOCAL FOLDER) almost always fails. This has been open for over a year now and no progress fixing it. I am on build 2004091906
Product: MailNews → Core
John Malmberg, your reports since bug 89285 was fixed have been about an apparent side-problem, bug 221633, which has a workaround (fixing paths in prefs.js) described at the dupe bug 219107. In comment 14, you said 221633 is "fixed", but the status of the original symptom here is not addressed. Bug 206408 is reportedly, like this bug, about an error message with both IMAP and local-folder copies (also suggested as a dupe to 89285); bug 298229 is about a hang while copying to Sent with POP. There have been numerous fixes to address various IMAP-copy-to-sent problems since the last post to this bug; in just the last year, bug 123063, bug 163951 and bug 287658 have had patches checked in.
Assignee: mscott → nobody
QA Contact: grylchan → mailnews.networking
Product: Core → MailNews Core
John, do you still see the original problem?
I am not in a position to test for this problem, and will not be for a while.
Thanks John. I think it's fair to do => incomplete until retested, given the passage of years, and fixing of previously cited bugs. Please reopen if you can reproduce in version 3 when it becomes available.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
This still happens for me on occasion, with tb3
You need to log in before you can comment on or make changes to this bug.