89606 - IMAP message goes blank until restart if another message is selected immediately after - N620 [@ Distance - nsScanner::RewindToMark]

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Lorenzo Colitti]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2001062815

A message on an IMAP server will go blank if another message is selected too
quickly after it. If you then do a "show message source" on the offending
message, mozilla freezes. When a message goes blank it will stay blank until
mozilla is restarted.

Reproducible: Always
Steps to Reproduce:
1. Start mozilla
2. Open mail+news and display the inbox of an IMAP server
3. Click on a message (A) and very quickly click on another message (B)
4. Now click on message A again

Actual Results:  In the preview pane mozilla incorrectly displays the headers of
message B and message content is blank.

To display the message correctly Mozilla has to be restarted completely.

Also, if you do a "Show Message Source" on the blank message, mozilla freezes.

Expected Results:  Mozilla should display the headers of message A and the
content of message A and should not freeze if "View Message Source" is selected.

Once a message displays properly it never goes blank until mozilla is restarted.

Messages also go blank in the same way when clicking on them on the first time
under other circumstances that I can't figure out. This method works every time
though.

The problem does not seem to occur if you use the keyboard instead of the mouse
to select the messages.

I have also seen cases of IMAP messages partially loading, but have not been
able to reproduce these consistently. It may be a related problem.

I have verified the problem on three different IMAP servers, so it seems to be a
 bug in mozilla.

This bug may be related to the following:
86383, IMAP occasionally truncates new mail messages on 0.9.1 Mozilla
82360, MS Exchange IMAP: Empty message bodies for some messages from MS Exchnage
mail server

Comment 1

[Lorenzo Colitti]

"Show message source" on the bogus message sometimes does nothing, sometimes
freezes, and sometimes causes a crash due to an invalid page fault in module
XPCOM.DLL.

I have no Talkback ID unfortunately, the talkback server seems to be down.

Comment 2

[Lorenzo Colitti]

Talkback ID is TB32632929Z

Comment 3

[Lorenzo Colitti]

I'm still seeing this bug on Mozilla 0.9.3 (Linux 2001080104 and Windows). Can
anybody confirm or WORKSFORME it at least?

Comment 4

[Alex Stewart]

FWIW, This repeatably happens for me on 2001080814 under Linux too (quite
annoying, also).

Comment 5

[Keyser Sose]

Need another talkback id that one is bad.

Comment 6

[Lorenzo Colitti]

Ok, here's another talkback ID: TB35012373K

Comment 7

[Asa Dotzler [:asa]]

Incident ID 35012373
Stack Signature Distance() ce1b4d3b
Bug ID
Trigger Time 2001-09-06 01:34:52
Email Address
User Comments
Build ID 2001080104
Product ID MozillaTrunk
Platform ID LinuxIntel
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Stack Trace
Distance()
nsScanner::RewindToMark()
nsParser::Tokenize()
nsParser::ResumeParse()
nsParser::OnDataAvailable()
nsDocumentOpenInfo::OnDataAvailable()
nsMimeBaseEmitter::Complete()
nsStreamConverter::OnStopRequest()
nsDocumentOpenInfo::OnStopRequest()
nsImapCacheStreamListener::OnStopRequest()
Process()
nsStorageTransport::AsyncRead()
AsyncRead()
nsImapMockChannel::ReadFromMemCache()
nsImapMockChannel::OnCacheEntryAvailable()
XPTC_InvokeByIndex()
EventHandler()
PL_HandleEvent()
PL_ProcessEventsBeforeID()
processQueue()
nsVoidArray::EnumerateForwards()
nsAppShell::ProcessBeforeID()
handle_gdk_event()
libgdk-1.2.so.0 + 0x17d00 (0x40341d00) 

Comment 8

[Scott MacGregor]

adding some keywords. Karen, can you see if you can reproduce this in house?

Comment 9

[Keyser Sose]

Dupe

*** This bug has been marked as a duplicate of 71498 ***

Comment 10

[Lorenzo Colitti]

Er... the crash may be a duplicate of 71498, but this bug is not about the
crash, it's about messages going blank.

The crash is just a side effect... maybe this should be reopened?

Comment 11

[Karen Huang]

Lorenzo,

Can you try again for the latest build?
Except the crash problem, I cannot reproduce other problem that you mentioned
above for that latest 09-14-04-0.9.4 build.

I tested on a plain text msg & attach a 8MB text msg. Switch between those msgs
is working fine.

Can I know what's the size of your A msg & B msg?
Are they all plain text msgs?

If you cannot reproduce the problem again, let's mark as verified for this bug.
If you can reproduce the problem on the latest build again, can you reopen this
bug?

Comment 12

[Alex Stewart]

FWIW (as I had posted a "me too"), I just tried quite a few attempts with 0.9.4
(build 2001091323) and as far as I can tell, this problem has been fixed for me.

Comment 13

[Lorenzo Colitti]

I am still seeing the problem with 0.9.4 (2001091303 Win98)

Any message is OK, but you must make sure the message has never been read since
starting mozilla. I have just reproduced the problem with two bugzilla emails,
which are both plain text and 1 KB in size.

I don't know if this happens with locally downloaded messages also, but I would
think it probably doesn't. Make sure your messages are not local but reside on
the server.

I repeat the steps to reproduce the problem:

1. Close Mozilla
2. Open Mozilla
3. Launch mail
4. Open an IMAP folder
5. Click on a message (A) and very quickly, *before it has loaded*, click on
another message (B).
6. Click on message A. Mozilla displays the headers of message B and an empty
message body.

Comment 14

[Alex Stewart]

Correction:  I just managed to do this in 0.9.4 also (it's not quite as easy as
it was, but it does still happen).  It should be noted that before it was
possible to hit this both using the keyboard (up & down arrows) to select
messages and via the mouse.  Apparently the keyboard situation has been greatly
improved, but selecting messages with the mouse still hits this bug repeatably
if you get the timing right.

Comment 15

[Scott MacGregor]

not an emojo stopper.

Comment 16

[Jay Patel [:jay]]

Adding N620 [@ Distance -  nsScanner::RewindToMark] to summary for tracking.  I
found a few crashes with recent N620 branch builds (which might lead to this
being a topcrasher with our next release) that might be related to this:

Distance   3
71498 	 RESO 	 FIXE 	 [e-mail] mozilla0.9.1 	 2001-09-25
BBID range: 36780145 - 36780561
Min/Max Seconds since last crash: 76 - 4666
Min/Max Runtime: 4666 - 5175
Crash data range: 2001-10-16 to 2001-10-16
Build ID range: 2001101605 to 2001101605
Keyword List : 
Stack Trace: 

	 Distance()
	 nsScanner::RewindToMark()
	 nsParser::Tokenize()
	 nsParser::ResumeParse()
	 nsParser::OnDataAvailable()
	 nsDocumentOpenInfo::OnDataAvailable()
	 nsMimeBaseEmitter::Complete()
	 nsStreamConverter::OnStopRequest()
	 nsDocumentOpenInfo::OnStopRequest()
	 nsMsgProtocol::OnStopRequest()
	 nsMailboxProtocol::OnStopRequest()
	 nsOnStopRequestEvent::HandleEvent()
	 nsARequestObserverEvent::HandlePLEvent()
	 PL_HandleEvent()
	 PL_ProcessEventsBeforeID()
	 processQueue()
	 nsVoidArray::EnumerateForwards()
	 nsAppShell::ProcessBeforeID()
	 handle_gdk_event()
	 libgdk-1.2.so.0 + 0x1716b (0x4033716b)
	 libglib-1.2.so.0 + 0x10055 (0x40367055)
	 libglib-1.2.so.0 + 0x10659 (0x40367659)
	 libglib-1.2.so.0 + 0x107e8 (0x403677e8)
	 libgtk-1.2.so.0 + 0x9165b (0x4027c65b)
	 nsAppShell::Run()
	 nsAppShellService::Run()
	 main1()
	 main()
	 libc.so.6 + 0x1c177 (0x404a8177)     (36780561)	Comments: Big boom!  Message goes booom!
     (36780145)	Comments: I had one of those '1969' messages in a POP3 inbox  after copying
and then attempting to move that POP3 message to the trash folder.  When I went
to view source  the app crashed!


This might be a slightly different issue, but it looks related...here is a
comment from bug 71498:

------- Additional Comments From [e-mail] 2001-08-07 23:48 -------

It looks like this is a slightly different bug.  This time the UnknownDecoder is
not on the stack...  It looks like this time it is nsStreamConverter (in
mail/news) which is calling OnDataAvailable(...) with an empty input stream :-(

take a look at:
http://lxr.mozilla.org/mozilla/source/mailnews/mime/emitters/src/nsMimeBaseEmitter.cpp#855

it looks Available(...) could be returning 0, but we still call ODA(...).

Comment 17

[scottputterman]

cc'ing ducarroz.

Comment 18

[scottputterman]

any chance this is related to http://bugzilla.mozilla.org/show_bug.cgi?id=108067

Comment 19

[Scott MacGregor]

the fix for this looks easy. I'll see if I can reproduce it in the debugger.....

Comment 20

[Scott MacGregor]

Attachment: the fix (don't call ODA if we don't have any bytes in the input stream)

Comment 21

[Scott MacGregor]

Comment on attachment 61297 [details] [diff] [review]
the fix (don't call ODA if we don't have any bytes in the input stream)

sr=sspitzer

Comment 22

[Scott MacGregor]

I checked in the change to put a if (numBytes) before calling ODA.

Comment 23

[Jan Carpenter]

Verified, stack signature not showing up in trunk, M097, or N621

Comment 24

[Lorenzo Colitti]

Ok, the crash is fixed.

But the summary still says "IMAP message goes blank until restart if another
message is selected immediately after". The bug *is not* fixed yet...

Trying to reopen.
Or should I open another bug with the same title?

Comment 25

[scottputterman]

Lorenzo,  I take it from your last comment that you can still see this on recent
builds.  I am unable to reproduce this.  Karen, have you had any luck?

Comment 26

[scottputterman]

removing the crash keywords to get out of my topcrash query.  If it's decided we
need a separate bug, whoever files the new one should feel free to add them back.

Comment 27

[Lorenzo Colitti]

Yes, I have been seeing it consistently in every build I tried since I reported
it. The procedure remains the same:

1. Close Mozilla
2. Open Mozilla Mail
3. Open an IMAP folder
4. Click on a message and then *very quickly* click on the message after that
5. Click on the first message again

If you are on ISDN or dialup or have a slow computer, it's very easy to hit the
bug. It you have a fast connection and a fast computer it's more difficult, but
you should be able to hit it like this:

1. Open an IMAP folder and mark a message as unread (not the first one in the
folder). Call it B.
2. Close Mozilla
3. Open Mozilla
4. Open the same IMAP folder and go to the message /before/ the one you marked
unread. Call it A.
5. Click on message A and just after you click press the N key to go to message B.
6. Click on message A again.
7. If you were fast enough, you will see that Mozilla displays the headers of
message B and an empty message body.

You may think that it's not very irritating, but I would like to point out that:
 - People using IMAP over slow connections like ISDN or dialup or using slow
computers are going to be hit hard by this
 - Mozilla must be *restarted* to be able to see that message again, which means
closing all browser windows, compose windows, etc. etc.

I think what happens is that when you click on A Mozilla starts pulling the
message headers into the cache. When you click on B the fetch stops because
you're now fetching B. But when you click on A again, Mozilla thinks A is in the
cache and doesn't fetch it any more. But there is nothing in the cache, so
Mozilla displays the same headers as whatever message you were displaying before
and an empty body.

Comment 28

[Lorenzo Colitti]

Further investigation seems to show that this happens when Mozilla issues the
FETCH  command for message A, and then sends another FETCH for message B before
receiving the OK COMPLETED response for message A.

Is there anything I can provide to make it easier for you to debug the problem?
A mail log perhaps?

Comment 29

[Lorenzo Colitti]

Sorry, my instructions above were not very clear. In point 4 where I say "go to
the message /before/ the one you marked unread" I mean just scroll down to it.
Do not click on it or the bug will not show up.

Comment 30

[Scott MacGregor]

the remaining symptom of this bug sure does sound like a dup of 114571 which was
fixed on 12/18. Lorenzo were you using 097 or a nightly build when you last saw
this? I can't reproduce this since the fix for 114571 went into the tree. I was
able to see it before then. The problem was we weren't dooming the cache entry
if we got interrupted before we finished writing the message into the cache. 

Comment 31

[Lorenzo Colitti]

I was using 0.9.7. I'll let you know how it goes with 0.9.8, as it's just round
the corner, but indeed the two bugs sound very similar.

Funny how this bug originally brought up the issue, but then got sidetracked by
the crash so it took another bug report and another bug number to fix the problem.

But hey: if it works, then all's well that ends well... :-)

Comment 32

[Scott MacGregor]

I'm going to mark this as fixed since Lorenzo was using 0.9.7 which definetly
demonstrated the problem I described in that other bug and that fix will be in
0.9.8. Let's aggressively re-open if you see it in .9.8.

Comment 33

[Lorenzo Colitti]

Can't seem to hit this on 0.9.8 at all (2002020406 WinME). Confirming fixed.