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)
Tracking
(Not tracked)
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.
Comment 1•23 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 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 :)
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•23 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.
Reporter | ||
Comment 3•23 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.
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•23 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. :)
-Brice
Comment 6•23 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•23 years ago
|
||
Reporter | ||
Comment 8•23 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•23 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•23 years ago
|
||
Is this bug dup of bug 81208?
Reporter | ||
Comment 11•23 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•23 years ago
|
||
Yes. Thanks for the response.
Adding bug 93210 for this bug dependance
Depends on: 93210
Comment 13•23 years ago
|
||
*** Bug 78511 has been marked as a duplicate of this bug. ***
Comment 14•23 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•23 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
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → LATER
Comment 17•23 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.
->Reopening
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Comment 18•22 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?
Comment 19•22 years ago
|
||
*** Bug 144074 has been marked as a duplicate of this bug. ***
Comment 20•22 years ago
|
||
*** Bug 127868 has been marked as a duplicate of this bug. ***
Comment 21•21 years ago
|
||
Problem still exists in 1.4RC1
Comment 22•21 years ago
|
||
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 ago → 21 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•