Closed Bug 24456 Opened 26 years ago Closed 25 years ago

Thread View, cannot delete last message

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mcafee, Assigned: Bienvenu)

Details

WinNT, threadview. I cannot delete the last message, it jumps up to an earlier message, leaving my last message there.
Assignee: phil → putterman
QA Contact: lchiang → esther
reassign to scott
Not every last message does this, but if you read your mail for ? 10 min. I eventually find one that "sticks" at the end. Not sure if I have any other clues yet.
This has happened to me quite a bit, but I can't reproduce it at will.
Chris, is this still happening to you? I haven't seen this in a while.
I can reproduce a problem where I can't delete anymore. The selection doesn't jump around (but that's probably because I changed it so that the selection won't change until after the delete happens and the delete doesn't happen.). I'm going to assume I'm seeing the same thing. I was commenting on this in 20653. "The reason is because at some point m_copyState in the trash folder isn't getting cleared out which causes nsImapMailFolder::InitCopyState to return NS_ERROR_OUT_OF_MEMORY which cuts the delete short. cc'ing jefft for any ideas."
Status: NEW → ASSIGNED
This isn't conclusive so maybe someone else can try this out for me. I tried doing this with closing the splitter between the thread pane and message pane. This makes it so that we never load any messages. When I did this I was able to keep deleting for a little over three minutes without seeing any problems. Then I opened up the splitter and within one minute I was in this state again. I wonder if there is a bad state we can get into when running the display url and the delete url a bunch of times in succession? cc'ing mscott for possible ideas. I'll try this again to make sure it wasn't a fluke.
My theory has possibilities. I just closed the splitter and spent 5 minutes deleting 300 messages without any problems. I opened up the splitter and after deleting 12 messages I was no longer able to delete any more. The only difference was that we were no longer loading the next message.
I have seen this problem but never figured out why.
It's hard to do this in the debugger so I've been putting in printfs. This is what I see, on the first one that fails, OnStartRunningUrl isn't called either.
One thing that is hard is that we tend to queue all the imap requests in queue. If one failed we kind of stuck. We need to address this problem one way or the other. I guess.
I'm going to reassign this to jefft. I hope you don't mind. I'm now tracing through code I don't really know. I've put in a bunch of printfs. If I did them right then we aren't adding to the url queue in the case that doesn't work.
Assignee: putterman → jefft
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: M15
Target Milestone: M15 → M16
I don't think we should wait until M16 to fix this bug. This is a pretty major bug. I reassigned it because after spending a day looking for this I couldn't figure out what was going on and it looks like it's happening in Imap code. There's a chance it was something I changed, but I don't know what's going on here. there's about a bug a day being filed which I can't prove, but am pretty sure is a dup of this bug.
I just reproduced this on Pop. So, it's not an Imap bug. So, it's probably some copy/move/delete bug. Perhaps pop will be easier to debug.
I don't seem have this problem. It works for me on my Windows and Linux box.
Wait I could be on drug. Isn't this something related to the PDT+ bug I am working on yesterday regarding the nextMessage to select. If we failed to get the nextMessage the message copy (a.k.a delete) won't happen.
You are not on drugs, I hope, but I'm pretty sure that the bug you mentioned is fixed in the build I'm working on and I'm not seeing any js errors like I was with that bug.
Interesting. On pop it's failing because it can't find the trash folder after the first delete.
Yes, I saw that yesterday in my debugger. First time you have no problem finding the TrashFolder. Then all of a suddent you couldn't find it anymore. This may related to some of the delete bugs. For some reason GetFoldersWithFlags() failed.
adding bienvenu for advice. I have a feeling what I'm commenting on is a separate bug, but just in case it's not I'll mention it here. I know why the pop delete isn't working. So, when the trash folder is created, SetFlags is called on it. Currently all SetFlags does is change mFlags. Then when the first delete is done, we're told to UpdateSummaryTotals. This causes us to go to the dbFolderInfo and get the flags, but since the trash flags were never add to the dbfolderinfo, it comes back with 0 and suddenly the trash flags is overwritten and the next delete won't happen. I saw this on my machine at home in regard to Biff when getting the Inbox. If I change SetFlags to add the flag to the folderInfo this also doesn't work because the db hasn't been loaded. And I don't think we want to force the db to get loaded for every folder we create. I think we need to be interacting with the cache here somehow. Any ideas?
OK. Jeff I see that in nsMsgDBFolder.cpp you removed the part where it set the cached flag on the flags. My guess is that that was in there to prevent us from regetting the flags and just using mFlags. I will see if this makes a difference. I could be wrong.
hmm. It looks like those changes probably didn't make a difference because force is always true. But something must have changed recently that's causing the trash folder to get overwritten.
OK. Those changes did cause it. I backed out the changes to nsMsgFolder.*, nsMsgDBFolder.* and nsMsgFolderFlags.h with the comment "fixed unnecessary database loading when building folder view;" and I can now delete pop messages again. As I said, I doubt this is the same bug, but it has the same result.
I think things are starting to make sense now. The reason it worked before is because mPrefFlags was being reset, not mFlags. I don't know the 4.x code base too well, but I'm guessing that there was a distinction between mPrefFlags and mFlags. My guess is that mPrefFlags were only set and saved for those flags that could be saved in the prefs, like Drafts, Templates, and Sent folder. And, things like Trash weren't saved in it. So either we need to continue the differentiation or we need to ensure that when a flag is set, that it is saved in the folderInfo so that it doesn't get reset the next time it gets read in.
The changes I made is after branch. So, prioir to the branch we have the problem too? Okay, I guess we need to have a whole complete picture on how things should work all together, cache, database, & memory version of all folder flags.
Like I said, I think these are different bugs and if I weren't lazy I'd probably open up another one :) The pop deleting problem is due to the changes to the flags you checked in. The other deleting problems mentioned in the bug are probably older and we still don't know what is causing them.
this is jeff's stuff.
I need to fix this in order to check in my other changes. The solution, I believe, is to write out flag changes to the DB (but only real changes, not any flag setting). The folder cache can be ignored, as long as you keep the DB in sync with the folder cache.
Assignee: jefft → bienvenu
Status: ASSIGNED → NEW
I have a fix for this.
Status: NEW → ASSIGNED
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Using builds 2000-05-17 on win98, mac and linux this is fixed. I tried putterman's scenario of closing message view, deleting and opening it back again. I deleted a total of 50 msgs in one session interrupting the delete by doing an undo too, all messages were deleted. Verified.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.