182641 - "marked as deleted" messages aren't deleted when "compacts folders" or "compact this folder" is selected, but unmarked as deleted instead

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Martin Jespersen]

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)
Build Identifier: 

well summary says it all. when i mark messages as deleted and then try to 
compact a folder then the marked messages just become unmarked intead of 
actually deleted.

the imap server in question is the UW IMAP server "IMAP4rev1 v12.264"

the same procedure works fine with netscape 4.* on the same imap server

Reproducible: Always

Steps to Reproduce:
1. mark one or more messages as deleted
2. select either "compact folders" from file menu or "compact this folder" from 
rightclickmenu on the foler in question

Actual Results:  
the marked messages becomes unmarked

Expected Results:  
the marked messages should have been deleted

Comment 1

[David :Bienvenu]

could you please attach a client-side protocol log? Thx!

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Comment 2

[Martin Jespersen]

Attachment: client-side imap session log

This is a client-side imap session log showing the problem (i hope). it seems
to me that when i mark somethinga s deleted mozilla never sends the mark
command to the server?! i can't see it anyway, and that wiould explain why it
says "No messages deleted, so no update needed"

Comment 3

[Martin Jespersen]

i have attached a log as requested

Comment 4

[Martin Jespersen]

maybe i should clarify: before i chose "compact this folder" and trighgered the 
expunge command i had marked a file for deletion.

Comment 5

[David :Bienvenu]

this server is telling us there are no permanent flags, so we don't bother
issuing a delete.

112[1f6da00]: mbj.dk:A:CreateNewLineFromSocket: * OK [PERMANENTFLAGS ()]
Permanent flags


you might try talking to the server people to figure out why it's saying that no
flags are permanent.

Comment 6

[Martin Jespersen]

That would be one way to solve the problem ofcourse, but not a solution that 
would make the mozilla mail-client better.

Besides it seems odd to me that every other client i've used for the past 4 
years (including netscape messanger v 4.xx) have worked perfectly with the 
server despite it's shortcomming on this point...   maybe the mail client in 
mozilla should issue the delete despite the lack of permanent flags, and thus 
work with imperfect server implementations.

Comment 7

[David :Bienvenu]

well, we're following the RFC. I guess we can stop following the RFC in this
respect. What flags do you think we should set? We should probably also set and
unset the /SEEN flag and the /FLAGGED flag so people can flag messages, and mark
them unread/read, and just ignore the PERMANENT FLAGS response entirely?

Comment 8

[Martin Jespersen]

That would probably be a really poor idea as your sarcasm so correctly 
indicates. 

A more productive approach would be to to ignore the lack of permanent flags if 
the server version in question is detected. This idea is not groundbreaking; 
People building websites have coded around browser defeciencies ever since the 
www started back in the 90's. It would be really nice if everyone would make 
perfect standard complient implementations, but then again it would be nice to 
live in a world where everyone is treated equal, noone was starving and the 
idealism could continue. Some of us however accept that utopia hasn't been 
reached yet, and then work with what we have and try to make the world a better 
place little by little.

If the developers of mozilla thinks that this approach to development is wrong, 
then by all means don't code the support for the servers lacks in standard 
compliance, but be aware that it will make the package useless to people who 
are stuck with servers that doesn't meet the standards you have set your mind 
to require... 

The real shame is that, in the eyes of those people, 2-4 year old software will 
look superior to what you are building now.

Comment 9

[David :Bienvenu]

I think it's a very bad idea to sniff server version strings for a lot of
obvious reasons and we don't and won't do that. I don't think it's a bad idea to
ignore the fact that some flag changes aren't going to be permanent - if the
server supports some flags (as indicated by the flags response) but won't let
them be permanent (as indicated by their absence in the permanent flags
response), well, we'll let the user set them for the current session. If the
server has erroneously indicated that the flags won't be permanent, but in fact
they are permanent, then everybody wins. Or does that sound evil to you?

Comment 10

[Martin Jespersen]

no, that doesn't sound evil at all, but very reasonable :)

Comment 11

[David :Bienvenu]

Attachment: proposed fix

if the server tells us there are no permanent flags (which is probably bogus),
we'll use the flags response as the flags we can set.

Comment 12

[David :Bienvenu]

Comment on attachment 107980 [details] [diff] [review]
proposed fix

this has r/sr=sspitzer

Comment 13

[David :Bienvenu]

fix checked in.

Comment 14

[esther]

qa contact change