I'm using the UW imapd in the default 'mbox' mode, so it's slow when those files get big. If I compose a message and send it, it takes as much as ten seconds to actually write the document to the 'Sent' folder. No sweat, because everything else still works. Except if you try sending a second message before the first one has completed. It will successfully deliver the mail message to the SMTP server, but it will generate a dialog box indicating it failed to talk to the IMAP server and giving you the chance to go back to the composition window. What should really happen, I suppose, is to either open another connection to the IMAP server or to queue the IMAP request behind the one that's pending. A secondary but related issue: when this happens, if you say "yes", take me back to the compose window, and then try to kill the window, it gives the normal warning that the message has not been sent, BUT IT HAS! You need to keep some state around for this.
FYI, I'm running Mozilla 0.9.8 on Win2000.
This is compounded by bug 129495 particularly over dial-up lines with large Sent mail folders. The long delay in writing to the sent folder begs the user to sent more mail while waiting. Result is that there is NO way to get the failed message into the sent folder without sending it again.
email@example.com -- Does this still happen on a recently nightly build? It's been quite a while since this bug was filed. :-) -M
I haven't seen the bug lately, but we recently got a much faster machine for our IMAP server. On the other hand, now Mozilla Mail is randomly wedging or crashing far more often, with no real discernable pattern.
All right. Well, do you think that you could close this bug, but try to work out what's causing your MozMail to crash now, and file a new bug with that? If you file it well, CC me on it and I'll see if I can confirm it. -M
It's up to whoever the bug is assigned to (Scott MacGregor) to decide whether to close it or whatnot. As to my most recent mail bug, if I can only figure out how to reproduce it, I'll file something. I've managed to generate several TalkBack things, but I don't know how those ultimately filter down to filed bugs.
All right. :-) Actually, since the bug is unconfirmed, you can close it if you'd like, since you're the reporter. I'm pretty sure that (especially with Netscape engineers) the engineers rarely look at Unconfirmed bugs, even if they are assigned to them. -M
Oh, and do you know what IMAP server is on the other end? Sometimes Mozilla has problems with certain IMAP Servers, and it'd be nice to narrow down what problems are related to what. :-) -M
Actually, it's not assigned to somebody until it's assigned. New or Unconfirmed bugs can be marked as WFM by the submitter. Going ahead and marking WFM.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.