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



18 years ago
5 years ago


(Reporter: sharding, Assigned: mscott)



Firefox Tracking Flags

(Not tracked)




18 years ago
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.

Comment 1

18 years ago
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       ESTABLISHED
TCP    sphinx:1430    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 :)
Ever confirmed: true

Comment 2

18 years ago
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.

Comment 3

18 years ago
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.

Comment 4

18 years ago
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).

Comment 5

17 years ago
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. :)


Comment 6

17 years ago
Yes..for my case, sometimes I need to switch (IMAP) folder and back so that
Mozilla is responsive and
list the folder content.

Comment 7

17 years ago
Dup of bug 81208 or bug 99228?
Reporter, can you try on the latest build? Is this problem still occurring?

Comment 8

17 years ago
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.

Comment 9

17 years ago
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

Comment 10

17 years ago
Is this bug dup of bug 81208?

Comment 11

17 years ago
Doesn't look similar to me. May be the same root cause, but my gut feeling is
that it's not.

Comment 12

17 years ago
Yes. Thanks for the response.
Adding bug 93210 for this bug dependance
Depends on: 93210

Comment 13

17 years ago
*** Bug 78511 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
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".

Comment 15

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → LATER

Comment 16

17 years ago

Comment 17

17 years ago
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.


Resolution: LATER → ---

Comment 18

17 years ago
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. ***

Comment 20

16 years ago
*** Bug 127868 has been marked as a duplicate of this bug. ***


16 years ago
QA Contact: huang → gchan

Comment 21

16 years ago
Problem still exists in 1.4RC1

Comment 22

16 years ago
This appears to be a duplicate of bug 42456

*** This bug has been marked as a duplicate of 42456 ***
Last Resolved: 17 years ago16 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.