105238 - deleted messages reset to unread in IMAP mailbox

Status: RESOLVED INVALID

(MailNews Core :: Networking: IMAP, defect)

Description

[Szelei Gabor]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
BuildID:    2001101202

after deletion UI set the read flag unread

Reproducible: Sometimes
Steps to Reproduce:
1.you should have several message in your IMAP INBOX/folder
2.delete it ->highlight goes down and message set to unread again
3.

Comment 1

[phule]

I see this bug when messages have not been "expunged" or purged from the IMAP
folder.  They show up as new/unread again.

Comment 2

[Jörg Thönnes]

The same behaviour is reproducible *everytime* using Mozilla 0.9.9 on Debian
Linux  2.2. The IMAP server is the freemailer web.de (imap.web.de):

fetchmail: 5.3.3 querying imap.web.de (protocol IMAP) at Tue, 26 Mar 2002
08:26:03 +0100 (CET)
fetchmail: IMAP< * OK WEB.DE IMAP4-Server
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ UIDPLUS X-NETSCAPE

Since I run a background fetchmail, it sometimes happens that if I delete a
message, fetchmail grabs it since it is marked as unread.

Perhaps Mozilla should reset the UNREAD flag explicitely.

Comment 3

[Jörg Thönnes]

In addition, if the deleted message marked UNREAD is selected, it is marked
READ (OK), but also the DELETED flag is cleared (WRONG).

If you are on the last message, both the UNREAD and the DELETED are left as is.
Otherwise, the GUI moves the selection to the next message. If this message is
marked UNREAD and DELETED, both flags are reset.

If there is only one message in the folder, the DELETE ACTION (keyboard or GUI)
toggles both UNREAD and DELETED.

Sounds as if DELETED and UNREAD are treated nearly the same. (cut & paste error?)

Comment 4

[Jörg Thönnes]

If the preview window is closed, the UNREAD flag is not cleared.
Then, if I open the preview window, the DELETE flag remains set.

On the other hand, if the preview window is already open, both the DELETE and
the UNREAD flag are cleared. (Only UNREAD should.)

Comment 5

[Boris 'pi' Piwinger]

Is this still happening?

pi

Comment 6

[Boris 'pi' Piwinger]

No response -> WFM.

pi

Comment 7

[Jörg Thönnes]

Yes, with Mozilla 1.0 this is still happening.

Comment 8

[Boris 'pi' Piwinger]

Can this be a conflict with fetchmail?

pi

Comment 9

[Jörg Thönnes]

My fetchmail is started via cron every 10 minutes. But the flags are changing
immediately. That is, fetchmail should not be the problem.

IMHO, the basic problem is some sort of linkage between the DELETED and the
(UN)READ flags. Is there some way to log the traffic between the Mozilla and
the IMAP server?

Jörg

Comment 10

[Boris 'pi' Piwinger]

Don't know how to catch that (except for network sniffer). Reopening and moving
over to Networking.

Interesting enough I cannot find any dupe, which is surprising.

Are you sure about the standards? Does the deleted flag imply read?

pi

Comment 11

[Boris 'pi' Piwinger]

Really over (reassigning).

pi

Comment 12

[Boris 'pi' Piwinger]

And new (suffering from bug 150955). There is certainly enough information to
double-check this problem.

pi

Comment 13

[Jörg Thönnes]

Attachment: tcpdump trace to imap.web.de (twice DELETE, DELETE and SEEN)

This traces the commands sent to the IMAP server from my Mozilla 1.0.
The trace starts after the login. The message preview window is closed.
In the message list, I chose one message (last message in list) and entered
the following commands in sequence:
1. key [DEL] - message is marked DELETED and UNREAD
2. key [DEL] - message is market !DELETED and !UNREAD
3. key [DEL] - message is marked DELETED and UNREAD
4. click NEW toggle - message is market !DELETED and !UNREAD

For every action, a command is sent to the server. As I can see, these are

1. +Flags (\Deleted)
2. -Flags (\Deleted)
3. +Flags (\Deleted)
4. +Flags (\Seen)

This seems OK, but the visual indication is NOT.

Comment 14

[Jörg Thönnes]

Attachment: tcpdump trace for imap.web.de (DELETE, DELETE, DELETE, SEEN)

Sorry, the trace missed the server replies. Now it is complete.

Obviously, the server echos only the flags set in last command. Should Mozilla
keep the state, ie set all current flags. That means

1. +\Deleted +\Seen
2. -\Deleted
3. +\Deletet +\Seen
4. +\Seen

Jörg

Comment 15

[David :Bienvenu]

taking, but might just be a server error.

Comment 16

[Rimas Kudelis [use needinfo to ping]]

I happenned to have a very similar problem (messages that I deleted, reapeared as new) which turned out to be an IMAP server problem (too many zombie processes were "taking care" of my mailbox, or something).

Comment 17

[David :Bienvenu]

that looks like a server error - the unsolicited FLAGS response should be all flags set on the message, from my reading of the RFC, and the way all other servers work. This allows the server to tell us if some other client has changed a flag on the message in the meantime...