[dogfood]Thread view out of sync



MailNews: Message Display
19 years ago
14 years ago


(Reporter: german, Assigned: Bienvenu)


Windows 98

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+] found fix - waiting for approval to check in - ETA 12/10)


(1 attachment)



19 years ago
Using the build from Dec 1, 1999, I am selecting a message in the threadview but
a different message appears. In fact I cannot access some of the messages at the
bottom of the thread list at all.


19 years ago
Assignee: phil → putterman


19 years ago
Whiteboard: [PDT+]

Comment 1

19 years ago
Putting on PDT+ radar.

Comment 2

19 years ago
German,  could you give me some more info on what is happening here?  Are you
around today?  I'm wondering if this is similar to the scrolling problem we have
when you scroll all the way down, select a message and then get bounced to the
top. When that happens you can't generally scroll down again until you play with
the scroll bar.  However, I haven't seen this display a different message than
the one you selected.

Comment 3

19 years ago
Created attachment 3210 [details]
proof from the 1202 build

Comment 4

19 years ago
it also seems to affect the wrong message when trying to delete or file, very
annoying as it accidentally destroys important mail messages


19 years ago
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 5

19 years ago
I can't reproduce this.  German said that after he removed the .msf file and
regenerated this, it is working again.  I'm going to mark this WORKSFORME.  If
it happens again then it should be reopened.  cc'ing bienvenu in case he knows
of anything that might have caused this.


19 years ago


19 years ago
Resolution: WORKSFORME → ---


19 years ago

Comment 6

19 years ago
German just reproduced this again with a build from yesterday.  This is what I
know. Maybe Jeff or David have ideas.

It's his POP Inbox.  It looks like it might be happening after GetMsgs.  Bug
20312 happened to him also. When downloading messages, it downloaded only 200 of
them.  But what's more interesting is that the message count shows up as there
only being 30 messages.  The first message displays correctly, but then when he
clicks on the second it gets messed up.  It looks like it's in the middle of
some other message and no headers show up.  Lots of errors start appearing in
the console.  Anyway, as the summary says, it looks like we are out of synch.

Does it sound like this could be related to the line ending problem that Jeff
fixed the other day?

Comment 7

19 years ago
Try remove old *.msf files. I suspect you have a corrupted summary file.

Comment 8

19 years ago
He did. that's why I reopened it.  He deleted his .msf file yesterday and
everything worked.  But this morning it is no longer working.

Comment 9

19 years ago
Scott, did you get a chance to examine his inbox. We may be able to tell what
went wrong if compare to imap view page source from 4.7. The other thing we
could do is to turn on the pop3 protocol logging.

set NSPR_LOG_FILE=e:\tmp\pop3_50.txt

Comment 10

19 years ago
I did that and put the file to http://blues/users/german/publish/pop3_50.txt
Actions I did while logging was on: Opened Messenger, Selected my inbox, clicked
on get messages, where it claimed that it downloaded 16 messages. The unread
message count in my inbox interstingly stayed at 24 where it was before. Then I
clicked on the last 3 messages from the bottom up in the threadpane. I always got
to see the same message which isn't even in the inbox according to the thread
view. Please Help. I am flying solo, and right now Mail 5 is the only mail client
I use :-)

Comment 11

19 years ago
It looks okay from the protocol point of view. We have a proper "QUIT" send to
the server indicating every thing is fine. Now the next would be to examine your
pop3 Inbox. It's a text file. You can view it using any text file editor. Note
pad will do fine. vi will be good. emacs will be the best. :-) Load your Inbox
into one of your text editor. Every line should have a proper endings and it
shouldn't be longer than 78(?) characters. Every message should have "From -
kkkk" dummy envelope header separate them to each other. Another possible thing
is you may have a corrupted Inbox. Try to delete the Inbox. Touch Inbox and then
re get msg.


19 years ago
Whiteboard: [PDT+] → [PDT+]Still looking. No ETA.

Comment 12

19 years ago
Inbox file looks OK to me. Every message is indeed properly separated. The from
headers are all there too. No line was found to be longer than 80 chars.

Comment 13

19 years ago
What happened if you remove the Inbox.msf file and then relaunch without Get
Msg? Can you see the message? If you cannot then we might have reparsing
the folder problem. If the message displayed okay, then try Get Msg. If that
screws up the inbox again then we might have incorparating new messages problem.

Comment 14

19 years ago
We just removed the .msf file and then it seemed to work. But as soon as we did
GetMsg, it messed up.  The headers didn't show up in the thread pane and then
when we clicked on a different message, it displayed the contents for the wrong

One thing we noticed is that there are 211 occurrences of "From -" but only 209
that begin a message.  There are occurences of ">From -" which I assume are
replies or Fwd's.  could this be causing a problem in terms of the message count
when downloading a message?

Comment 15

19 years ago
We should ignore the >From -. Do we think we have 209 messages? I wouldn't think
we'd have a problem parsing the mailbox, but we might have a problem when
downloading messages with embedded >From lines, if we have to escape the From
ourselves (this is a special case, because we insert the > ourselves)

Comment 16

19 years ago
Before we did a Get Msg we found the Inbox said it had 206 messages when we
think it had 209 based on a search we did for an empty line followed by "From -"
plus the first message.

Comment 17

19 years ago
Here's some more detail:
It happens after a combination of deleting messages with downloading new ones
afterwards. If then I select a certain message a different one gets displayed.
This only happens from a certain message on downward, so subsequent messages are
also corrupted. The first corrputed ones still display headers, the ones further
below, show just snippets of the messages content and even further below, it
would not show anything due to XUL errors (according to console). Messages above
the first broken one appear fine. Scott just witnessed that behavior on my machine.
Unfortunately it's hard to see a pattern.
BTW I downloaded fresh binaries build ID 1999120708, and tried - same thing there.

Comment 18

19 years ago
I still can't reproduce this on my machine even though I've watched German do
this on his.  One other note, as German said, the msg key must be messed up.
often time it will display a message that has been deleted.  I will try today's
release build to see if this makes any difference for me.

Comment 19

19 years ago
If anyone has any ideas on what else to check, I'd appreciate them.  I've seen
this happen multiple times on German's machine.  However, I can't reproduce it
on mine.  I've set up a profile that uses German's prefs.js and also has a
replica of his mail directory so it has all of the folders and all of the filter
rules.  And I'm grabbing mail from his account.  And everything works for me.
No combination of getting mail and deleting mail seems to be causing this.  The
only other difference I can think of is that I've got a much faster machine.  Is
there anything that could be timing related?

Comment 20

19 years ago
I'm not sure - is German really running win98? I doubt that's a difference,

Comment 21

19 years ago
Yes, that is definitely a difference.  He's running windows 98.

Comment 22

19 years ago
OK here's another blue's clue I found this morning:
I downloaded eight messages. 2 of which actually show up in the thread view of
the inbox. That's because the other six have been filtered away (moved using
filters from 4.x) into other folders. Now here's the clue:
The last previously downloaded message still displays OK. The next one displays
OK but actually it's content pane shows the content of first of the messages
which has been filtered to another folder. This tells me as a mere mortal that
something went wrong when the message was marked for getting moved/deleted. This
is because messages do not actually get deleted initially when being moved from
the originating folder. Instead they just get marked for deletion.
Now here's the weird part:
The next message after that is the first that start getting out of sync. So here
something seems to be wrong in addition where it is confusing the length of a
message that was marked for deletion with the length of the message that it was
supposed to display. Because it is assuming the wrong length of the previous
message, it gets the wrong entry point for this message, and starts displaying
it somewhere from the message middle of the body. That would explain why a)
initially messages don't display their headers anymore and then further down
even exhibit XUL errors, since chopping potentially used HTML in a message might
render that HTML invalid, thus XUL(XML) thinks the page is not well formed,
refusing to display it alltogether. Again this is just my speculation, but it
would explain some of these somehow seemingly unrelated weirdnesses. Just it
might help. BTW I am using POP3 and ca 90-100 filters.


19 years ago
Assignee: putterman → bienvenu

Comment 23

19 years ago
German, are you still using the Dec 1 build? Because I fixed a bug a while ago
very much like this - we're not supposed to leave the filtered message in the
inbox - that was fixed in the Dec 7 build. I'll take this bug, since it's
definitely mine, but it would really be helpful to know if you've downloaded a
more recent build.

Comment 24

19 years ago
I just checked and German's using the most recent build. Also, we removed
rules.dat so now filters were not applied and using the steps that seemed to
cause this problem, everything worked.


19 years ago
Whiteboard: [PDT+]Still looking. No ETA. → [PDT+]Still looking. Can reproduce but can't debug ETA 12/15

Comment 25

19 years ago
This only seems to happen on slow machines running win98 or win95. I determined
that the truncate after the move operation is failing. It doesn't seem to be
because the file is open, but because the truncate offset is invald (perhaps the
stream stuff doesn't flush during a close? that would suck)

Comment 26

19 years ago

Can I help you debug this today?  What code should I be looking in?

Comment 27

19 years ago
I'm debugging it now, remotely. Unless you can debug this with a debugger, I can
struggle along myself. The last thing I found out is nsFileSpec::Truncate is
failing in the win32 api SetEndOfFile, with an error code ERROR_ACCESS_DENIED.
This is strange, because the open call in truncate succeeds, and it opens for

Comment 28

19 years ago
OK, I think I have a fix for this - in nsFileSpec::Truncate, we're calling
CreateFile to open the file with the following flags : FILE_FLAG_NO_BUFFERING |
truncating doesn't fail. My guess is that nsFileSpec::Truncate does not work on
win95/win98. If you read the MSDN comments about FILE_FLAG_OVERLAPPED and
FILE_FLAG_NO_BUFFERING, it's pretty scary. I also notice them used in
nsLocalFile::SetFileSize(PRInt64 aFileSize) - if this is not obsolete, this
should be looked at as well.

I'll do some more testing to see if the problem is really fixed, but my first
test worked.


19 years ago
Whiteboard: [PDT+]Still looking. Can reproduce but can't debug ETA 12/15 → [PDT+] found fix - waiting for code review

Comment 29

19 years ago
OK, things seem to be working much better. I'll try to get a code review from


19 years ago
Whiteboard: [PDT+] found fix - waiting for code review → [PDT+] found fix - waiting for approval to check in - ETA 12/10

Comment 30

19 years ago
got a code review, just waiting for approval to checkin for chofmann. I'll ping
him again this afternoon.


19 years ago
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 31

19 years ago
German, can you try this again on Monday and see if you see any problems?
thanks for all your help!


19 years ago
Blocks: 21564


19 years ago
QA Contact: lchiang → suresh

Comment 32

19 years ago
german - can you try out this bug fix?
suresh - since the problem was reproducible on the system in your cubicle, I'm
going to make you qa contact to verify this bug. Thanks.


19 years ago

Comment 33

19 years ago
Verified this using 1999-12-14-09-M12 windows commercial build.


18 years ago
No longer blocks: 21564
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.