46888 - gets stuck on one msg, can't delete, move or view other msgs

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P2)

Description

[johng]

build 2000072704 and ealier (for at least a week), win95, pop

Happens frequently but hard to predict, though beginning to see a pattern.

What happens:
- easy to see if you are view the contents of a message in the 3rd pane
- you have just completed an action like delete, filed a message or ???
- immediately you try to delete or file or click on a different message to read
and you find that you can't.  Seems stuck on the message you were viewing - you
can't delete or file anything.  Even though you can select a different message,
you can't view the contents of that other message.

Pattern?:
Not sure, but it seems to happen when you click on a button (like delete or
instigate filing to a folder) or double click another message (to view in new
window) while an earlier process (like building the summary file of the trash
folder) is still running.

Comment 1

[johng]

nsbeta3 because this happens to me several times a day and makes the product
hard to use.

Comment 2

[David :Bienvenu]

John, not all mail bugs are mail database bugs :-) . I'm a bit confused what
criteria you're using to decide mail bugs are mail database bugs.

Comment 3

[lchiang]

+ per mail triage
We need to try to reproduce.  Per Scott, if we delete the message and the 
product thinks it's not done yet, we won't display anything else in the message 
pane. 

Comment 4

[lchiang]

P2 per mail triage

Comment 5

[johng]

I haven't run into this bug on later builds - might be ok to close if you can't 
reproduce.

By the way bienvenu, I just make the best guess I can for the component and 
leave y'all to figure out where it goes.  Sometimes I guess poorly, but what do 
you expect from the nav dude?  ;-)

Comment 6

[scottputterman]

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

Comment 7

[scottputterman]

reassigning to naving. We need a way to handle failed delete's so that we can
reset state that allows messages to be displayed.

Comment 8

[Phil Peterson]

PDT agrees P2

Comment 9

[David :Bienvenu]

adding to cc list. I wonder if we're not handling failure to get a folder lock -
I think we do lock local folders when modifying them.

Comment 10

[David :Bienvenu]

I can't recreate this either. I wonder, John, if you have check for new mail
turned on, and set to automatically download new messages. I can imagine
problems happening if you happen to be deleting a message right when a new
message is getting downloaded or something like that.

Comment 11

[selmer (gone)]

What's the current status on this bug?  If we can't reproduce it, we need to
know that very soon.

Comment 12

[Navin Gupta]

I have fixed cancelling of news message. In case of failed deletes the next
message should not be selected (remains to be done to close the bug). 

Comment 13

[David :Bienvenu]

Scott and I came up with a reproducible case of this involving clicking on a
large message, dragging it to another folder while still loading, and then
clicking on the destination folder after the drop happens. After that point, you
can't load messages. In our tests, it looked like the move wasn't finishing (or
starting), so of course no notification was sent. Debugging at home, it looks
like the move did happen, but the notification wasn't sent.

Comment 14

[David :Bienvenu]

I think our reproducible case doesn't work because of the following check in
HandleDeleteOrMoveMsgCompleted:

if(IsCurrentLoadedFolder(folder))

This will fail, because the delete/move is happening in a different folder than
is currrently selected, because we selected a different folder.

A simple fix for this would be to clear gNextMessageAfterDelete whenever we load
a folder. Do you want me to try that?

Comment 15

[scottputterman]

perhaps the best thing to do would be to clear the nextselectedmessage variable 
when changing folders. I think that would make sense since the nextselectmessage 
is no longer valid in this case. And that would free us up to display a message.

Yesterday when we were testing, I thought we weren't hitting the break points 
that send out the notifications. Was that not true?

Comment 16

[David :Bienvenu]

I got different results at home - don't know why. Yesterday, we weren't even
hitting the code that starts the move, but at home, I am hitting that code. I'll
try clearing that variable on folder load.

Comment 17

[scottputterman]

I haven't tried this out yet, but something like this might work:

Index: content/commandglue.js
===================================================================
RCS file: /cvsroot/mozilla/mailnews/base/resources/content/commandglue.js,v
retrieving revision 1.122
diff -c -r1.122 commandglue.js
*** commandglue.js	2000/09/14 05:36:45	1.122
--- commandglue.js	2000/09/20 16:38:32
***************
*** 174,180 ****
      
    gBeforeFolderLoadTime = new Date();
    gCurrentLoadingFolderURI = uri;
! 
    if(msgfolder.manyHeadersToDownload())
    {
  	try
--- 174,180 ----
      
    gBeforeFolderLoadTime = new Date();
    gCurrentLoadingFolderURI = uri;
!   gNextMessageAfterDelete = null;
    if(msgfolder.manyHeadersToDownload())
    {
  	try

The original bug doesn't seem to imply switching folders, but we've been having 
problems reproducing that case.

Comment 18

[scottputterman]

The patch makes this case work for me, too. It's interesting because I was also 
able to complete the move on my machine at home. I'm not sure why.  

Comment 19

[David :Bienvenu]

OK, I'll send the patch around to the reviewers and get it checked in, and then
try to reproduce this in other ways.

Comment 20

[scottputterman]

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

Comment 21

[scottputterman]

I checked in navin's changes to do some error handling in js code.  I don't know 
if we actually fixed this bug completely, but it's probably all we're going to 
do unless we get a more reproduceable case.  

Comment 22

[Phil Peterson]

Marking fixed to get verification help then. Probably not holding PR3 for this, 
so marking nsbeta3- too.

Comment 23

[laurel]

Attachment: talkback 18431596

Comment 24

[laurel]

Using PR3, 2000-09-29 mn6 commercial build: First time trying bienvenu's
reproducible case steps, I crashed ... talkback attached.  Don't know if I hit
some other case or what.  

Will try again several times with different messages, etc.

Comment 25

[David :Bienvenu]

adding Rich to cc list since that crash looks libmime related. It might depend
on the message involved, since neither Scott nor I crashed doing this, and we
were using the same large message

Comment 26

[laurel]

I was just able to do the case with a couple text only, no attachments kind of
messages and all was ok, except the move never moved the message from the Inbox
although it did appear in the destination folder, too; it copied.  Other,smaller
and uninterrupted moves work ok, though; they move instead of copy.

Will keep trying before reopening...could also use input from johng as to
whether he can recreate.

Comment 27

[laurel]

I'm not able to reproduce the problem using oct3 branch build, NT 4.0.
Will give a try on linux, mac...

Comment 28

[laurel]

I can't reproduce on either linux or mac with today's branch build.  
Putting vtrunk in keyword for trunk build verification.
JohnG: please add comments as to whether you're seeing this with current builds

Comment 29

[laurel]

OK with dec5 commercial trunk build, linux rh6.0, win98, mac OS 9.0