209188 - reading imap+ssl message occasionally stalls indefinitely

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Sean Cavanaugh]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529

when reading messages on an IMAP+SSL server, clicking the next message
occasionally causes mozilla to try to read a message indefinitely. The M icon in
the corner is constantly animated, but the message never reads. I have left
mozilla running overnight to see if it would time out and it didn't in over 10
hrs. This only seems to occur when reading a folder with many unread messages
(around 40+), and seems to happen randomly. This also occurs with earlier
versions of Mozilla (confirmed with 1.2.1, and 1.3.1). 

In earlier versions, pressing the stop button, loading a previously read message
(but not the last read one), then trying the unread message that mozilla stalled
on will cause the message to be read, but some of the previously read messages
are then marked as unread. The number marked unread varies from about 5 messages
to all the messages that have been read since opening the folder (in some cases
in excess of 100).

In 1.4, the mail window must be closed and reopened, since there is no stop
button. This has approximately the same effect as using the stop button as
described above.

I believe the mail server is running cyrus-imap, but since I do not own the
machine, I am not sure of versions or even if that is the server.

Reproducible: Sometimes

Steps to Reproduce:
1. open folder with many unread messages
2. read messages and hope it stalls


Actual Results:  
mozilla stalls until mail window is closed.

Expected Results:  
Opened the message.

This was tested with Mozilla 1.2.1, 1.3.1, and 1.4rc1 on Linux, Win2k, and
FreeBSD. It is present in all cases.

Comment 1

[Sean Cavanaugh]

Oops, should have been more clear on versions. 1.2.1 and 1.3.1 tested on Win2k
and FreeBSD, 1.2.1,1.3.1, and 1.4rc1 tested on Linux. 

Comment 2

[David :Bienvenu]

you can either press the <esc> key, or put the stop button back on your tool bar
(edit | preferences | mail & newsgroups | select buttons to appear on toolbar)

do you have any special prefs set, like checking folders other than the inbox
for new messages? Is it reproducible on certain messages?

Comment 3

[Sean Cavanaugh]

I'm not using any special prefs, just basic things (like enabling junk mail
controls). It occurs randomly. Once I cancel the read and attempt to re-read the
message it stalled on, the message is *always* read correctly. 

Comment 4

[David :Bienvenu]

I think the junk mail controls tend to make this worse because they cause us to
fetch all the new messages in the folder and that can cause a little bit of a
race condition. Roughly how often does this happen?

Comment 5

[Sean Cavanaugh]

This tends to happen about every 30 minutes or so, usually when skimming a
mailing list, ie going from one message to the next very quickly. I also noticed
that when there is a lot of other network traffic, such as a large file
transfer, it is much more likely to occur. 

Comment 6

[Tashfeen Bhimdi]

Don't know if it matters, but the IMAP server (University Server) I am
connecting to that experiences this problem is SSL ONLY, you can't connect to it
using a non-ssl connection.  I have talked about this Mozilla problem with the
server administrator, he has checked over the whole server and has not noticed
any problems on his end, he uses IMAP successfully with Pine.

I have another IMAP server (Fastmail.fm) setup in the same Mozilla config, it
works *perfectly*, with and without SSL.

Comment 7

[David :Bienvenu]

Attachment: attempt to fix race condition around m_urlInProgress

I don't know if this will help or not, but it attempts to fix a race
condition/contention around the setting and accessing of m_urlInProgress
between an imap thread and the ui thread.

Comment 8

[David :Bienvenu]

fixed - please let me know if this still happens to you...

Comment 9

[Scott MacGregor]

*** Bug 237246 has been marked as a duplicate of this bug. ***