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: