Closed Bug 87825 Opened 23 years ago Closed 21 years ago

Mozilla keeps IMAP connections open indefinitely when close "Mail/News".

Categories

(MailNews Core :: Networking: IMAP, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 42456

People

(Reporter: sharding, Assigned: mscott)

References

Details

This is basically the same thing as bug 69082, which was marked WORKSFORME. It may seem to work, but I've verified this on several builds on both Linux and FreeBSD and I don't think that it's desirable behavior. Mozilla will keep a connection to the IMAP server open indefinitely after all mail windows are closed (I had it keep one open for over a week without any use at all). Since the actual application isn't being exited, this does make some sense. But I don't think it's intuitive. The mail and news functionality in many ways seems like a seperate application, and my experience with most users of mail in Communicator indicates that they feel the same way. When they close the mail windows but not the browser, they feel that they have 'exited' mail. They didn't quit the app because they want to continue using the browser. No different in their view than quiting Eudora or Outlook and leaving Navigator running. A lot of people even leave the browser running all the time so they don't have to wait for it to launch again next time they need it. So when someone feels that they have exited mail and the app still has connections to the mail server (which may or many not cause problems if the user accesses their mail from elsewhere), they will be confused. This just doesn't seem like the "right" way for this to work. Sure, there will be some small savings in time next time the user opens the mail client. But that's relatively insignificant. If some see it as a major issue, maybe there could be a preference for connection persistence. Or let it stick around for some fixed amount of time (30 minutes?) and then go away if still unused. I don't know what the solution is, but I feel that this is a problem which merits more attention. If nothing else, keeping unused connections around that waste resources on the client and server isn't friendly behavior.
I can agree that this is a behaviour that should be changed. I just closed Mail and still have an open IMAP connection to the mailserver. I can remember how confused I was when I first got a message about an read only mailbox when I tried to read my mailbox via webmail. Additionally there seems to be an open connection to the news server: TCP sphinx:1426 62.144.129.100:143 ESTABLISHED TCP sphinx:1430 h-204-29-187-152.netscape.com:nntp ESTABLISHED My personal opinion is that Mozilla should close connections when closing MailNews. I find myself closing the entiere app from time to time to check if mail really works when an expected mail does not arrive ;) At least a pref would be nice :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mozilla should still be checking for new mail when the mailnews window is closed, so doesn't it need to keep the connection open to do this? Maybe not.
Well, I guess that's a matter of opinion. I don't think it should be checking for new mail when mailnews is closed. If I want to know about new mail, I'll have a mail window open. If it's closed, it should leave the mail server alone. I'm not opposed to having this be a preference, but I am definitely opposed to leaving it as it is.
I agree with closing the connection. Especially with IMAP servers, where I know of at least one (courier-imap) that counts open connections, and will only handle so many (IMAP can potentially be highly resource heavy).
I'm seeing a problem that seems to be related to the way Mozilla handles connections - when mail comes into my INBOX (courier-imap), more than likely, it gets filtered (client-side, via Mozilla mail filters) into a subfolder. Often, when I switch over to see what mail I've received, I'll see that a new message is in a subfolder, so I'll click on that subfolder (or hit 'N' for Next) at which time Mozilla appears to think that a connection to the folder is still open (since it filtered a message into it), but my IMAP server has since closed the connection. The result is that Mozilla just hangs there until I do something else, like click back to INBOX and then back to my subfolder - usually Mozilla then opens a new connection, but depending on the timing, it will not 'forget' that it thinks it has a connection open and I'll have to exit Mozilla entirely to get back into that subfolder. The scenario I detailed is one aspect of this problem - the other is if a person has their 'Sent' messages folder on the server (relatively common if you access your mail from various stations). What happens here is that sending mail waits an inordinately long time on 'copying message to Sent folder' because Moz thinks its connection is still open when in fact the server has closed it. After a while, the send operation times out and a message is displayed indicating that the sending of the message succeeded, but copying it failed. This gets pretty annoying pretty quickly and again, sometimes the very next message will be stored properly, sometimes exiting Mozilla is required to 'reset' Mozilla's memory. So, is this related? If not, is another bug addressing this already? Should I file a new bug? This particular issue has been around since way back in NS4 - I have users complaining *all the time* that they get server disconnect messages w/ NS4.7x. Highly annoying as I'm sure you can imagine. :) -Brice
Yes..for my case, sometimes I need to switch (IMAP) folder and back so that Mozilla is responsive and list the folder content.
Dup of bug 81208 or bug 99228? Reporter, can you try on the latest build? Is this problem still occurring?
Yes, this still happens in the 10-02 nightly. After closing all mail windows, Mozilla maintains a connection to the IMAP server. This is highly undesirable.
It still occurs in 2001110903 ... A workaround is to click twice the online/offline button in the lower right corner, which will quickly close the existing connections. A new connection will be opened by biff later if mail-checking is configured. See also bug 93210
Is this bug dup of bug 81208?
Doesn't look similar to me. May be the same root cause, but my gut feeling is that it's not.
Yes. Thanks for the response. Adding bug 93210 for this bug dependance
Depends on: 93210
*** Bug 78511 has been marked as a duplicate of this bug. ***
Oops! They should be different. Removing bug 93210 from this bugs dependance since they are different bugs. Bug 93210 mentioned that we should send the "LOGOUT" command when quit "Mozilla" whole application, and this bug mentioned that Mozilla keeps IMAP connections open indefinitely when close "Mail/News". Should this bug "won't fix" bug since it is the way our client works.....
No longer depends on: 93210
Summary: Mozilla keeps IMAP connections open indefinitely → Mozilla keeps IMAP connections open indefinitely when close "Mail/News".
Changing the status to enhancement and Resolving as LATER since the problem described is a bug which will not be fixed in this version of the product.....
Severity: normal → enhancement
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → LATER
Verified.
Status: RESOLVED → VERIFIED
There is no "this version of product". I don't think any bug should be resolved this way and this LATER resolution should be deprecated. It's fine to let the bug be NEW with Target Milestone in Future or not set. But this way as it is no one finds it when searching for dupes. ->Reopening
Status: VERIFIED → REOPENED
Resolution: LATER → ---
I have the same problem here with 2002061104 (1.1a) / Win32. Are there any plans to fix that bug in the 1.1 release?
*** Bug 144074 has been marked as a duplicate of this bug. ***
*** Bug 127868 has been marked as a duplicate of this bug. ***
QA Contact: huang → gchan
Problem still exists in 1.4RC1
This appears to be a duplicate of bug 42456 *** This bug has been marked as a duplicate of 42456 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago21 years ago
Resolution: --- → DUPLICATE
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.