If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

I can delete only one message from 'Unsent Messages'-folder

VERIFIED FIXED in mozilla1.3final


MailNews Core
15 years ago
9 years ago


(Reporter: smaug, Assigned: (not reading, please use seth@sspitzer.org instead))



Bug Flags:
blocking1.3 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [1.3 final candidate] fixed1.3)


(1 attachment, 2 obsolete attachments)

5.82 KB, patch
Details | Diff | Splinter Review


15 years ago
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:

Comment 1

15 years ago
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.

Comment 2

15 years ago
Mozilla 1.2.1 works fine but 1.3a doesn't.
Keywords: regression

Comment 3

15 years ago
I'll look into it when I can.
Component: Mail Database → Mail Back End
Ever confirmed: true

Comment 4

15 years ago
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?

Comment 5

15 years ago
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.

Comment 6

15 years ago
I wonder why this happens only in 'Unsent Messages' -folder.
Other local folders work fine until I make some changes to the
'Unsent Messages'.

Comment 7

15 years ago
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?

Comment 8

15 years ago
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.)
Flags: blocking1.3?

Comment 9

15 years ago
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. ***

Comment 18

15 years ago
High-visibility mail regression. Setting to blocking 1.3
Flags: blocking1.3? → blocking1.3+
Assignee: bienvenu → sspitzer
Target Milestone: --- → mozilla1.3final
I re-assigned to fast, bienvenu might have cycles to fix this.

he's already started to wrap his head around it.
Assignee: sspitzer → bienvenu

Comment 21

15 years ago
After "Compact Folders" I can't reproduce the problem.

Comment 22

15 years ago
Oops, I can see the problem again after restarting.


15 years ago
Attachment #113614 - Attachment is obsolete: true

Comment 23

15 years ago
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

Comment 24

15 years ago
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

Attachment #114606 - Flags: superreview?(bienvenu)
Attachment #114606 - Flags: review?(naving)

Comment 26

15 years ago
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. 

Comment 27

15 years ago
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.

Comment 28

15 years ago
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
Assignee: bienvenu → sspitzer

Comment 30

15 years ago
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.

Comment 31

15 years ago
*** 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.
Attachment #114606 - Flags: superreview?(sspitzer)
Attachment #114606 - Flags: superreview?(bienvenu)
Attachment #114606 - Flags: review?(sspitzer)
Attachment #114606 - Flags: review?(naving)
trying out a different fix.  hope to have a patch very soon.
Keywords: nsbeta1
Created attachment 115606 [details] [diff] [review]

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.
Attachment #114606 - Attachment is obsolete: true
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)
OS: Linux → All
Hardware: PC → All
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.
Last Resolved: 15 years ago
Resolution: --- → FIXED
Whiteboard: [1.3 final candidate]
Target Milestone: mozilla1.3final → mozilla1.4alpha
I've re-opened the dups, as they are something else.

Comment 39

15 years ago
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.

Comment 41

15 years ago
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.
Attachment #114606 - Flags: superreview?(sspitzer)
Attachment #114606 - Flags: superreview-
Attachment #114606 - Flags: review?(sspitzer)
Attachment #114606 - Flags: review-
fix backported to 1.3 final.
Target Milestone: mozilla1.4alpha → mozilla1.3final


15 years ago
Whiteboard: [1.3 final candidate] → [1.3 final candidate] fixed1.3

Comment 44

15 years ago
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

Comment 45

15 years ago
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
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.