Closed Bug 20634 Opened 25 years ago Closed 25 years ago

[dogfood]Thread view out of sync

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: german, Assigned: Bienvenu)

Details

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

Attachments

(1 file)

proof from the 1202 build
7.39 KB, image/gif
Details
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.
Assignee: phil → putterman
Whiteboard: [PDT+]
Putting on PDT+ radar.
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.
Attached image proof from the 1202 build —
it also seems to affect the wrong message when trying to delete or file, very annoying as it accidentally destroys important mail messages
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → ASSIGNED
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?
Try remove old *.msf files. I suspect you have a corrupted summary file.
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.
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 set NSPR_LOG_MODULES=POP3:5
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 :-)
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.
Whiteboard: [PDT+] → [PDT+]Still looking. No ETA.
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.
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.
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 message. 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?
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)
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.
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.
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.
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?
I'm not sure - is German really running win98? I doubt that's a difference, however.
Yes, that is definitely a difference. He's running windows 98.
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.
Assignee: putterman → bienvenu
Status: ASSIGNED → NEW
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.
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.
Status: NEW → ASSIGNED
Whiteboard: [PDT+]Still looking. No ETA. → [PDT+]Still looking. Can reproduce but can't debug ETA 12/15
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)
David, Can I help you debug this today? What code should I be looking in?
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 write.
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 | FILE_FLAG_OVERLAPPED. If I change these to just FILE_ATTRIBUTE_NORMAL, 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.
Whiteboard: [PDT+]Still looking. Can reproduce but can't debug ETA 12/15 → [PDT+] found fix - waiting for code review
OK, things seem to be working much better. I'll try to get a code review from Doubg.
Whiteboard: [PDT+] found fix - waiting for code review → [PDT+] found fix - waiting for approval to check in - ETA 12/10
got a code review, just waiting for approval to checkin for chofmann. I'll ping him again this afternoon.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
German, can you try this again on Monday and see if you see any problems? thanks for all your help!
Blocks: 21564
QA Contact: lchiang → suresh
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.
Status: RESOLVED → VERIFIED
Verified this using 1999-12-14-09-M12 windows commercial build.
No longer blocks: 21564
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: