Closed Bug 184959 Opened 22 years ago Closed 22 years ago

After delete message(s) operation, unable to delete again for folders of same server

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 192780

People

(Reporter: black, Assigned: sspitzer)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021211 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021211 I delete either a single message, or a number of selected messages in one delete operation in my inbox folder. After doing this I am unable to delete any more messages in that folder or in other folders belonging to that mail server. Inbox folder contains 2864 messages, it is a pop mail server. Reproducible: Always Steps to Reproduce: 1.Choose inbox for pop account 2.Select a message or a number of messages in the inbox folder 3.Delete those messages 4.Select another message in any folder on the same server 5.Attempt to delete that message Actual Results: No message is deleted in step 5. Expected Results: Deleted the message selected in step 4. After performing above procedure, I can, however, delete messages in folders belonging to others servers (local mail, other pop accounts, etc) Even weirder: if I undelete, I am able to redo to delete the message, but it doesn't show up in the mail menu until I scroll away and return. I can exit and reload mozilla and be able to repeat the problem (I can do one delete, then no more) Yes, I know this works for you. ;) It works for me too, for other accounts, just not this one account for some reason.
QA Contact: olgam → gchan
Here is the error message in the debug window: ###!!! ASSERTION: Last delete did not complete: 'PR_FALSE', file f:/mozsrc/mozi la/mailnews/base/src/nsMsgDBView.cpp, line 2300 Break: at file f:/mozsrc/mozilla/mailnews/base/src/nsMsgDBView.cpp, line 2300 Here is the stack trace: (user defined break point, not a crash) NTDLL! 77f97704() nsDebug::Assertion(const char * 0x0301c5b4, const char * 0x0301c5a8, const char * 0x0301c574, int 2300) line 280 + 13 bytes nsMsgDBView::DeleteMessages(nsIMsgWindow * 0x042b7280, unsigned int * 0x04c686a8, int 1, int 0) line 2300 + 35 bytes nsMsgDBView::ApplyCommandToIndices(int 7, unsigned int * 0x04c686a8, int 1) line 2128 + 48 bytes nsMsgDBView::DoCommand(nsMsgDBView * const 0x04d7d798, int 7) line 1942 + 20 bytes XPTC_InvokeByIndex(nsISupports * 0x04d7d798, unsigned int 7, unsigned int 1, nsXPTCVariant * 0x0012b324) line 106 XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode CALL_METHOD) line 2016 + 42 bytes XPC_WN_CallMethod(JSContext * 0x02bc9018, JSObject * 0x04be6a58, unsigned int 1, long * 0x04300990, long * 0x0012b5d4) line 1292 + 14 bytes js_Invoke(JSContext * 0x02bc9018, unsigned int 1, unsigned int 0) line 839 + 23 bytes js_Interpret(JSContext * 0x02bc9018, long * 0x0012bef0) line 2803 + 15 bytes js_Invoke(JSContext * 0x02bc9018, unsigned int 1, unsigned int 2) line 856 + 13 bytes nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x049eabd8, nsXPCWrappedJS * 0x049ec0c0, unsigned short 5, const nsXPTMethodInfo * 0x017c49a8, nsXPTCMiniVariant * 0x0012c3e4) line 1200 + 21 bytes nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x049ec0c0, unsigned short 5, const nsXPTMethodInfo * 0x017c49a8, nsXPTCMiniVariant * 0x0012c3e4) line 430 PrepareAndDispatch(nsXPTCStubBase * 0x049ec0c0, unsigned int 5, unsigned int * 0x0012c494, unsigned int * 0x0012c484) line 115 + 31 bytes SharedStub() line 139 XPTC_InvokeByIndex(nsISupports * 0x049ec0c0, unsigned int 5, unsigned int 1, nsXPTCVariant * 0x0012c600) line 106 XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode CALL_METHOD) line 2016 + 42 bytes XPC_WN_CallMethod(JSContext * 0x02bc9018, JSObject * 0x02bf6aa8, unsigned int 1, long * 0x04300958, long * 0x0012c8b0) line 1292 + 14 bytes js_Invoke(JSContext * 0x02bc9018, unsigned int 1, unsigned int 0) line 839 + 23 bytes js_Interpret(JSContext * 0x02bc9018, long * 0x0012d1cc) line 2803 + 15 bytes js_Invoke(JSContext * 0x02bc9018, unsigned int 1, unsigned int 2) line 856 + 13 bytes js_InternalInvoke(JSContext * 0x02bc9018, JSObject * 0x03997a58, long 62977672, unsigned int 0, unsigned int 1, long * 0x0012d42c, long * 0x0012d2fc) line 931 + 20 bytes JS_CallFunctionValue(JSContext * 0x02bc9018, JSObject * 0x03997a58, long 62977672, unsigned int 1, long * 0x0012d42c, long * 0x0012d2fc) line 3431 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x02bc8e30, void * 0x03997a58, void * 0x03c0f688, unsigned int 1, void * 0x0012d42c, int * 0x0012d430, int 0) line 1041 + 33 bytes nsJSEventListener::HandleEvent(nsJSEventListener * const 0x04c99b20, nsIDOMEvent * 0x0430b298) line 182 + 77 bytes nsXBLPrototypeHandler::ExecuteHandler(nsXBLPrototypeHandler * const 0x02ece830, nsIDOMEventReceiver * 0x04c66118, nsIDOMEvent * 0x0430b298) line 457 nsXBLWindowHandler::WalkHandlersInternal(nsIDOMEvent * 0x0430b298, nsIAtom * 0x02d8ed10, nsIXBLPrototypeHandler * 0x04c36b48) line 311 + 48 bytes nsXBLWindowKeyHandler::WalkHandlers(nsXBLWindowKeyHandler * const 0x02ec0c98, nsIDOMEvent * 0x0430b298, nsIAtom * 0x02d8ed10) line 182 nsXBLWindowKeyHandler::KeyPress(nsXBLWindowKeyHandler * const 0x02ec0c98, nsIDOMEvent * 0x0430b298) line 198 nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x02de8650, nsIPresContext * 0x02de3470, nsEvent * 0x0012f7a4, nsIDOMEvent * * 0x0012f43c, nsIDOMEventTarget * 0x02e0f768, unsigned int 2, nsEventStatus * 0x0012f5dc) line 1657 + 41 bytes nsXULDocument::HandleDOMEvent(nsXULDocument * const 0x02e0f738, nsIPresContext * 0x02de3470, nsEvent * 0x0012f7a4, nsIDOMEvent * * 0x0012f43c, unsigned int 2, nsEventStatus * 0x0012f5dc) line 2563 nsXULElement::HandleDOMEvent(nsXULElement * const 0x03729200, nsIPresContext * 0x02de3470, nsEvent * 0x0012f7a4, nsIDOMEvent * * 0x0012f43c, unsigned int 2, nsEventStatus * 0x0012f5dc) line 3387 + 44 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x0379f518, nsIPresContext * 0x02de3470, nsEvent * 0x0012f7a4, nsIDOMEvent * * 0x0012f43c, unsigned int 2, nsEventStatus * 0x0012f5dc) line 3381 + 58 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x0379fc40, nsIPresContext * 0x02de3470, nsEvent * 0x0012f7a4, nsIDOMEvent * * 0x0012f43c, unsigned int 2, nsEventStatus * 0x0012f5dc) line 3381 + 58 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x0379fec0, nsIPresContext * 0x02de3470, nsEvent * 0x0012f7a4, nsIDOMEvent * * 0x0012f43c, unsigned int 2, nsEventStatus * 0x0012f5dc) line 3381 + 58 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x037a0350, nsIPresContext * 0x02de3470, nsEvent * 0x0012f7a4, nsIDOMEvent * * 0x0012f43c, unsigned int 7, nsEventStatus * 0x0012f5dc) line 3381 + 58 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f7a4, nsIView * 0x02de3ea8, unsigned int 1, nsEventStatus * 0x0012f5dc) line 6130 + 47 bytes PresShell::HandleEvent(PresShell * const 0x02de7b64, nsIView * 0x02de3ea8, nsGUIEvent * 0x0012f7a4, nsEventStatus * 0x0012f5dc, int 1, int & 1) line 6053 + 25 bytes nsViewManager::HandleEvent(nsView * 0x02de3ea8, nsGUIEvent * 0x0012f7a4, int 0) line 2163 nsView::HandleEvent(nsViewManager * 0x02de3c68, nsGUIEvent * 0x0012f7a4, int 0) line 304 nsViewManager::DispatchEvent(nsViewManager * const 0x02de3c68, nsGUIEvent * 0x0012f7a4, nsEventStatus * 0x0012f714) line 1943 + 23 bytes HandleEvent(nsGUIEvent * 0x0012f7a4) line 83 nsWindow::DispatchEvent(nsWindow * const 0x02de3f54, nsGUIEvent * 0x0012f7a4, nsEventStatus & nsEventStatus_eIgnore) line 1116 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f7a4) line 1137 nsWindow::DispatchKeyEvent(unsigned int 131, unsigned short 0, unsigned int 46, long 22216705) line 3017 + 15 bytes nsWindow::OnKeyDown(unsigned int 46, unsigned int 339, long 22216705) line 3060 nsWindow::ProcessMessage(unsigned int 256, unsigned int 46, long 22216705, long * 0x0012fc48) line 4012 + 38 bytes nsWindow::WindowProc(HWND__ * 0x00080342, unsigned int 256, unsigned int 46, long 22216705) line 1403 + 27 bytes USER32! 77e11d0a() USER32! 77e11bc8() USER32! 77e11cef() nsAppShellService::Run(nsAppShellService * const 0x01244180) line 472 main1(int 1, char * * 0x00277cf8, nsISupports * 0x00277d70) line 1543 + 32 bytes main(int 1, char * * 0x00277cf8) line 1904 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e9ca90()
you're right, it works for me. using commerical trunk on xp: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021216 Do you know what type of mail server you are using (courier, cyrus, netscape mesg server, exchange, etc..)? I think you would be running into bug 182808 but that fix was checked in on 12-11. Does this happen with a new profile? Do you have pref "delete mesgs on server when they are deleted or moved from my inbox" checked? Anything unique with mesgs you are deleting (attachments, etc..)? nsMsgDBView.cpp hasn't been modified in a while. it was modified on 12-13 after you had your problem. Did this used to work on previous mozilla build?
Component: Mail Window Front End → Mail Back End
yeah, this is a dup of http://bugzilla.mozilla.org/show_bug.cgi?id=183766 or http://bugzilla.mozilla.org/show_bug.cgi?id=182808 and should be fixed now. *** This bug has been marked as a duplicate of 182808 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
I'm going to re-open this since it doesn't seem to be a dup of bug 182808. Let's continue the discussion here. some more questions - do you have a trash folder for this server? Can you click on it and see if the trash gets reparsed?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Yes, I have a trash folder for this server. When I delete the message as described above the message(s) arrive there. I tried emptying the trash but that didn't make the problem go away. I'm not sure how to tell if it is being reparsed, but, I click on the trash folder and I can see recently deleted messages (including messages from the first delete of the session). I can scroll around, sort, etc. This is without restarting.
Hal, do you actually have source code and a debugger to debug this? If so, I can suggest some places to set breakpoints, etc. Also, have you tried creating a new profile and adding this account to it, and seeing if the problem still persists? If it's something to do with this account, that would help narrow down the problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yes, I have a debugger. I will start a pull of the latest source code. I haven't tried a new profile with the same account. I kind of doubt I will see a problem since it is just a pop account that pulls the data, I don't leave it on the server or anything. But I'll give it a go.
Okay, I created a new profile for that account. The bug didn't show up. 8'( Anyway, let me know some breakpoints to try.
The notification that should be sent to the js is sent from nsMsgLocalMailFolder::EndCopy(), in this line towards the end: if (srcFolder && !mCopyState->m_isFolder) srcFolder->NotifyFolderEvent(mDeleteOrMoveMsgCompletedAtom); Do we get to ::EndCopy, and if so, do we get to the NotifyFolderEvent call? if not, why not? nsMsgLocalMailFolder::DeleteMessages is where the delete process starts - I'm pretty sure that's getting called if the message is getting into the trash. If you have AIM, I can send you my screen name and we can step through it over AIM.
OK, after much help from Hal, we've found out that there are two RDF resources for the INBOX, one with INBOX and one with Inbox. Removing INBOX.msf fixes the problem. This profile was migrated from 4.x. I'm going to look at the .msf file to see what's going on. My guess is that the changes made to support localized pretty names for special folders probably caused this.
also, I suspect that one of the folders was found with GetResource, and one with FindFolderWithURI (or something similar), and that's how we ended up comparing two different folders resources.
Status: NEW → ASSIGNED
at least one cause of this problem was the changes to the copy service to support multiple copy sources (see bug 66955). We're using the folder from the msg Hdr instead of the actual src folder, and it seems in this case, those can be different folders. I'm not convinced that code is really needed, since nsMsgSearchDBView seems to separate the requests into different folders - maybe it doesn't do that for drag+drop; I'll have to check.
David, I usually migrate my 4.x profile on windows and haven't run into this problem. Though my mail acnt is imap and not pop. If there are some test situations you want me to run, let me know.
I use my account since 4.7 and I had this Problem, too. I was only able to delete one time - doesn't matter if it is one file or twenty marked files to delete. Deleting the inbox.msf was also a good idea for me. First time I restarted I could delete as many messages i wanted to. But today, after the second restart - there it was again. Only one time deleting... . Maybe it depended on the date and mozilla decided to work right in holy night :-) If neccessary, excuse my english.
After deleting the .msf file, it worked for a bit, and now the bug behavior is back for me as well.
I had reporteded this earlier than then was moved to another bugtraq (182808), but my problem sound closer to this bug: I downloaded and installed the 12/24 Windows release (uninstalled and deleted the my previous Mozilla)and I still have the same symptoms: I block-mark several e-mails and can delete them successfully, but then I try to delete one more but can't. I exit out and go back in, and then I'm able to delete just one e-mail before it stops working again. This is on a Win98se system and I'm just pulling down from a pop3 server. I've gone through a number of recent builds but nothing "sticks" in regards to fixing this. I will try archiving my existing e-mail under a separate profile and use a new profile for fresh e-mail, but this is not a good thing.
Similar symtoms on Win98SE, Mozilla 1.3b (2002122604), with the following observations: Once I delete in my primary POP account, I can not delete in it again, nor can I view the contents of any other message (that is, I am stuck on the contents of the message after the deleted one) *until I view another pop account*. Deletes function normally in non-primary POP accounts. If I delete in a non-primary account, I can now view other messages in the primary POP account, but still no more deletes until I shut down Mozilla and restart
Re: comment <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=184959#c10">#10</a> and comment <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=184959#c15">#15</a> I too have migrated from 4.7 and have a folder listed as "Inbox" in the Mail pane, but as "INBOX.msf" in my profile's directory. Deleting the *.msf files only help for a little while. I too suffer from Bug <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=182808">#182808</a>. I'm using an IMAP account.
Anyway, I am guessing that there are other bugs of higher priority than this one to fix, so I found a workaround (which doesn't solve the core problem of migrating profiles). Here's what I did: Close mozilla Go to the folder where your mail folders are stored. For mail folders that are in ALL CAPS: 1. Delete the .msf file 2. Rename the mail folder file to make it have the first letter capitalized, the rest of the letters lower case*. (i.e. INBOX becomes Inbox, DRAFTS becomes Drafts) * I only have single-word folder names, not sure how multiple word filenames work If you have a lot of mail, mozilla mail will take a while to load, don't panic. 8') I did this a few days ago and can now delete as often as I please.
yes, that's the appropriate work-around. The fix in the code would either involve undoing the damage of the fix for bug 66955, which would be a bit involved since that code is needed for handling move/copy/delete from search results spanning multiple folders, or figuring out a way of making sure that we end up with the same folder. I think the root cause is that the js front end passes a list of uri's of messages to move/copy to the back end, and when converting those uri's to folders, we must be getting a different INBOX folder (INBOX instead of Inbox, or vice versa).
usign commerical trunk on XP Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030106 I tried migrating a pop account from 4.x that had mesgs in the inbox, unsent,sent, and folders with various capitalization (Foo,FOO,FoO). I had no problem deleting mesgs from any of those folders. Reporters/David am I missing a step?
I tried the 1/19/03 Win build and got the same old can't-delete-after-deleting thing, BUT then thought to try compacting the Inbox folder and everything started working fine and dandy again afterwards. (Perhaps a general "Clean and Repair" function under Tools that empties the Trash and then rebuilds the mail folders would be a handy fix-all function to have.)
I had the same problem after upgrading to 1.3 from 1.2.1, which I had migrated from 4.x. Deleting all caps *.msf (INBOX.msf and others) solved the problem. I'm on Win/98 with a POP account.
An update: Deleting INBOX.msf only fixes the problem during the session that the msf is rebuilt. The msf is rebuilt as "INBOX.msf", not "Inbox.msf". After Mozilla is exited and restarted, the delete problem again exists. But I can always delete messages by dragging to Trash. Also, my rules that move messages to Trash always work.
I think I've found a more permanent work-around: 1. Delete the problem account (this does not delete the existing mail files, fortunately). 2. Create a new account with the same settings. This creates a new folder in the "Mail" folder, similarly named. In my case, the original folder was "mail1.onr.com". The new folder is "mail.onr-1.com". 3. Close mozilla. Copy all non-msf files from the original folder (e.g. "mail1.onr.com") to the new folder (e.g. "mail.onr-1.com"). 4. When mozilla rebuilds the msf, it is now "Inbox.msf", not "INBOX.msf". And deletes seem to work properly!
Dan, Check out comment 19 for a less destructive permanent workaround.
The steps in <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=184959#c19">comment 19</A> do not work for me. I get the symptoms described in <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=184959#c24">comment 24</A> - it is always rebuilt as INBOX.msf
comment 25 also does not work for me - it still rebuilds INBOX.msf. I am running the 1.3 release code, on Win98 SE. I can still only delete once in the main inbox folder. When I go into a subfolder for the first time, it rebuilds the msf file for that subfolder and I get unlimited deletes in the subfolder, even after restarting Mozilla. The subfolder indexes are built with a lower case file name, however. My workaround has been to create a subfolder 'aaaa' and a filter that runs last that puts everything in that folder.
My Sent folder is having the same symptoms as Inbox - rebuilds as SENT.msf, one delete only. Perhaps it is size related? 3000+ notes in Inbox, 900+ in sent.
Steve, So your "Sent" folder appears as "Sent" in Mozilla appears as "Sent" on the filesystem but the msf file appears as SENT.msf?
Like Steve, my Inbox folder appears as Inbox in Mozilla, as Inbox in the filesystem, but as INBOX.msf.
Yes, my Sent folders are as described in comment 30. I did another delete/rebuild cycle just now to verify
Dup of bug 192780?
Well, sorry that workaround doesn't work for you guys. 8'( If bug 192780 is a dup of this bug (looks like it is), then hopefully the fix will be in the tree soon.
resolving this as a dup of 192780. reporters of this problem please take builds with fix for 192780 to verify your specific case is fixed too. Thanks! *** This bug has been marked as a duplicate of 192780 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
verified
Status: RESOLVED → VERIFIED
verified - I am able to delete from Inbox and Sent
QA Contact: gchan → esther
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.