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

Unread messages in newFolder marked as read after filter moves IMAP/inbox -> IMAP/newFolder

RESOLVED INCOMPLETE

Status

SeaMonkey
MailNews: Message Display
RESOLVED INCOMPLETE
6 years ago
2 years ago

People

(Reporter: casio7131, Unassigned, NeedInfo)

Tracking

SeaMonkey 2.9 Branch
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
I have a message filter that moves messages from IMAP/inbox -> IMAP/newFolder (based on "from" address) - this is the only message filter I use.  When new messages arrive, they are moved to the new folder (named "00stuff/svn"), and that folder is marked as having unread messages (ie. folder "svn" is shown in bold text, say "svn (2)" if 2 messages were filtered).  Now, when I then click on the "svn" folder, these (say 2) unread messages are now marked as read, even though I haven't clicked on them yet.

With the previous/expected behaviour, the unread messages would remain marked as unread when I click on "svn" folder.

I attach some screenshots to illustrate:
1) 1 new message has been filtered.  Note the bold "svn (1)".
http://i.imgur.com/ZSqS3.png
2) I then click in "svn" folder.  The unread message get marked as read, even though I haven't read/clicked on them yet.  Note that this screenshot is taken just after I've clicked on "svn" folder and I have scrolled right to the top/newest message in the list.
http://i.imgur.com/gWPvs.png

My system is:
Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1

PS. I think this has been happening for a week or so, which roughly corresponds to the release of SM 2.9 - I can't be exactly sure of when this started though, because I didn't make an exact note of it.

Comment 1

6 years ago
There were several problems with mail in 2.9 including Filters. But these should have been fixed in 2.9.1
(Reporter)

Comment 2

6 years ago
Well I've just disabled the message filter for now (since it's easy enough for me to manually move the messages to a new folder).

Strange - I just manually dragged 2 unread messages from (IMAP) inbox to svn folder and I see the same behaviour (ie. when I then click in svn folder, these 2 unread message are now marked as read).  Don't know if this will help?

Unless I'm asked to try anything else, my plan is just to wait and test again once a new SM is released.
(Reporter)

Comment 3

5 years ago
Testing with latest version: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10

Same behaviour - manually dragging 2 unread messages to a new folder and then these 2 messages are marked as read after clicking on the new folder.

If I can be bothered, I might try some more tests with a fresh profile: SM 2.10 and latest TB.
(Reporter)

Comment 4

5 years ago
Well just tested with a fresh/test profile using TB 13.0 (en-GB version) and I see same behaviour when dragging unread messages.

Comment 5

2 years ago
NOT reporducible with DE SeaMonkey 2.35(γ)  (Windows NT 6.1; WOW64; rv:38.0 nightly by Adrian Kalla)  Gecko/20100101 Build 20150616034436 (Classic Theme) on German WIN7 64bit

I did lots of variations with drag and drop, drag and drop paste from inbox to inbox-subfolder or account folder, I never saw that dropped unread mails became "read".

But I am not able to create new subfolders for my new test folders, that only works for inbox. I will test that later.

@reporter:
a) do you still see the problem with current SeaMonkey version and a current OS?
b) If yes, can you reproduce your problem with a new subfolder below inbox and 
   manual drag and drop from inbox to that new subfolder?
Flags: needinfo?(casio7131)

Comment 6

2 years ago
c) Due to Comment 4 this one might be a mail-core problem.

Comment 7

2 years ago
No response, so I close this one for now.
@Reporter: Please feel free to reopen this Bug if you still can reproduce the problem with a current SeaMonkey version and a current OS and if you can contribute a step by step instruction due to <https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines>  (containing every key press and every mouse click) how to reproduce the problem reliably.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.