User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030205 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030205 I can delete only one message from 'Unsent Messages'-folder. After that the folder is somehow locked. Reproducible: Always Steps to Reproduce:
Created attachment 113614 [details] [diff] [review] a hack. And here is some kind of hack. It allows me to delete more messages, but the UI is not updated properly.
Mozilla 1.2.1 works fine but 1.3a doesn't.
I'll look into it when I can.
I have tried to find the real problem. But because I don't know the code of the MailNews very well, it takes some time (and no results?). Maybe the fix is just so simple that I can't see it. Anyway, for some reason nsCopyRequests are not released every time. (My hack makes a ClearRequest -call too early. The UI problems are actually there even without the patch.) In nsMsgCopyService::NotifyCompletion() there is a FindRequest()-call, which returns null when trying to delete messages in the 'Unsent Messages' -folder. The copyRequest->m_srcSupport.get() == aSupport in FindRequest() is for some reason false. But why it is false? Has someone called the NotifyCompletion() or nsMsgCopyService::CopyMessages() with wrong parameters or is the problem somewhere else?
You're doing well for not knowing the code! Anyway, I believe the problem is a mismatch in uri's. What happens is the js front end takes the selection of messages and creates a list of uri's of messages to delete and passes that to the c++ backend. The backend converts those into message keys in a db and manipulates them that way. Eventually, the move/copy code converts them back into uri's and tries to find the folder for the uri, but ends up with a different folder because of either an upper/lower case problem, or a uri escaping problem (the former is the one I've seen for some people with the INBOX/Inbox). Eventually, nsMsgCopyService::FindRequest fails when trying to remove the just succeeded move, because the src supports don't match. Once that fails, we can't do any more deletes, because we think we're still handling a delete for the src folder. I haven't had time to figure out how to fix this.
I wonder why this happens only in 'Unsent Messages' -folder. Other local folders work fine until I make some changes to the 'Unsent Messages'.
because something funny is happening with the uri for that folder. Do you have an entry for mail.default_sendlater_uri in your prefs.js?
mail.default_sendlater_uri pref does not make any difference. I hope someone fixes this before 1.3. (I'll do it, if I have time to learn more about mailnews.)
Using build 20030210 (1.3b) on Win98 a friend of mine expierenced this behaviour for his inbox folder - reproducible always. Told him to try Shift-Del and it works fine... hope this helps (For me, using win2k and the above mentioned build with my profile on a network drive both works fine - no problems so far)
*** Bug 192780 has been marked as a duplicate of this bug. ***
*** Bug 192548 has been marked as a duplicate of this bug. ***
*** Bug 192251 has been marked as a duplicate of this bug. ***
*** Bug 191029 has been marked as a duplicate of this bug. ***
*** Bug 191342 has been marked as a duplicate of this bug. ***
*** Bug 187467 has been marked as a duplicate of this bug. ***
*** Bug 184271 has been marked as a duplicate of this bug. ***
*** Bug 193026 has been marked as a duplicate of this bug. ***
High-visibility mail regression. Setting to blocking 1.3
I re-assigned to fast, bienvenu might have cycles to fix this. he's already started to wrap his head around it.
After "Compact Folders" I can't reproduce the problem.
Oops, I can see the problem again after restarting.
Created attachment 114606 [details] [diff] [review] proposed fix v. 0.1 I noticed that this bug is a regression from bug 178570. This patch basically removes navin's patch and uses bienvenu's code.
Cool. However, I'm not sure why Navin's patch was better than mine - I don't know if backing out his patch and using mine will break localization of special folder names, or japanese folder names. Cc'ing Navin in case he remembers.
Comment on attachment 114606 [details] [diff] [review] proposed fix v. 0.1 We need some fast r= and sr= love here for 1.3, or this is going to miss the train. /be
I believe I did that for a reason. I don't remember it now. You might want to play around with japanese folder names. I have not been working on mozilla for months now.
There are some other problems with folders and deleting messages. I just made one nonsense (local) folder "ð↓↓ø" and it was impossible to delete any messages from that folder. The problem was there with and without the patch.
But the ð↓↓ø -problem is something else than this bug because it occurs in 1.2.1 too. This bug is a regression between 1.2.1 and 1.3a.
taking back, so I can look into this and drive it in for 1.3 final
I've always found delete unreliably and quite flakey. I haven't used anything newer than 1.2.1. All versions I've tried in the last year have had problems. I see this with a fresh install and mail imported from Netscape 4.79. Sometimes when I delete messages or folders they appear in the trash as a copy rather than being moved. Once it starts happening in a session, every attempt to delete behaves the same way. I have to restart Mozilla, although I might have to do this many times to delete my imported mail folder by folder. I've taken to doing it by hand in Explorer (Win2K). Of course, I can only attempt to delete once I know it's seen all the messages in the folder, which can take several restarts and deletions of the summary files (it sometimes only recognises 700 of the 2,400 messages in my inbox.) Not sure if it's related to this bug though.
*** Bug 194769 has been marked as a duplicate of this bug. ***
Comment on attachment 114606 [details] [diff] [review] proposed fix v. 0.1 taking review requests. I'm not sure this is the right thing yet.
trying out a different fix. hope to have a patch very soon.
Created attachment 115606 [details] [diff] [review] patch the problem for the "Unsent Messages" folder came with the fix for bug #57440 the problem is that FindSubFolder() expects the folder name to be escaped.
but that patch doesn't explain any of the duplicates, which should be reopened. some of the duplicates might be dups of each other, but not dups of this.
not just linux -> all. here's how I reproduced this: send later two emails, exit. restart, and select the unsent messages folder, and try to delete the messages (one at time)
fixed on the trunk. this has r/sr bienvenu I'll wait for this to bake (and to be verified) before I see approval for 1.3 final.
I've re-opened the dups, as they are something else.
Works fine now. Thanks sspitzer.
about the other bugs, bienvenu gives me a clue. if they are all problems with the inbox, it is a related issue: INBOX vs Inbox. I'll go look into it.
Seth, can you go ahead and land this on the branch? If the verification doesn't go well we can back it out. I'd rather more testing than less. Thanks.
Comment on attachment 114606 [details] [diff] [review] proposed fix v. 0.1 this wasn't the fix that landed.
fix backported to 1.3 final.
Using trunk builds 20030228 on winxp, macosx and linux and seeing the problem with a broken build running Seth's reproducible case in comment 36 this is fixed. Verified
I Can delete first message, but second, thrirty,... not. Very, very estrange. When I do multi-select for delete messages, first delete is OK, but next delete will be fail. I have mozilla Mozilla 1.3b Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210