Closed Bug 201917 Opened 21 years ago Closed 20 years ago

messages deleted by filter are 'unread' in trash

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
trivial

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mozilla, Assigned: Bienvenu)

Details

(Whiteboard: [see comment 14]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Messages apear as unread in the trash folder even if the message filter that put
them there has 'mark as unread' marked.

Reproducible: Always

Steps to Reproduce:
1. Create any message filter that deletes the message and marks it as read.
2. Receive a message that is caught by the filter.
3.

Actual Results:  
The message will apear in the trash box as unread.

Expected Results:  
The message should apear in the trash box as read and the trash folder should
not be in bold characters, nor should it have the number of unread messages in
it increased (in the label).
Assaf Lavie: I cannot duplicate this problem with 1.3 Final.  I tried using two 
different rule combos:
 - Delete message and Mark message unread
 - Move to [trash] and Mark message unread

In both cases, the message was properly marked and relocated to the trash.

By any chance do you have other rules running prior to this one, which may be 
deleting but not marking as read?
It seems you got me all wrong. I'm not trying to keep the message _unread_ in
the trash but, on the contrary, I want it to appear as _read_ when it is deleted
into the trash so it won't bug me. This bug is still occuring on my setup.
Sorry, I misposted:  I did set it up as "mark as read", not "mark as unread",
and that was the result I achieved.

My question about additional rules still stands.
Ok.
Now the problem that bothers me is not that the message that gets moved to the
trash stays unread but that the label of the Trash folder becomes bold so as to
indicate a new unread message. So even though the message _is_ deleted or moved
and marked as read the label of the Trash folder turns to Bold which prompts me
to look inside for new mail - which I hate to do.
I apologize if I hadn't made that clear form the begining. But never the less
this behavior is a bug.

I did understand that, but I neglected to include it in my report of my attempts 
to duplicate.  For me, the Trash is *not* being bolded or updated with a number 
of unread messages -- in 1.3 Final, with the Orbit theme.

However, I was able to get mail working again, kinda, in the 0426 build of 1.4b, 
which I am running without a theme.  In this version of the program, I am seeing 
the Trash folder turn bold (but without a message count) when the 
message-as-read is filtered into it.  (Note that a filter of 'Delete message' is 
exactly equivalent to 'Mark message as read + Move message to Trash'.)

Marking as read and moving to a non-Trash folder has the same result, except 
that the folder name is also marked with the green arrow; apparently Trash never 
gets a green arrow.

This is related to Bug 107206, but the specific candidate for duplication is Bug 
167619.  (See also Bug 46133.)
Assaf: is this for a POP or IMAP mail account?  And, do you have a theme
installed? (Preferences|Appearance|Themes)
Additional notes on confirmation of this bug:

I duplicated the symptom using POP mail, 1.4b (0426), as described in comment 5. 
I noticed a slight difference if the mail arrives while viewing the folder to 
which the mail is moved:  if the folder is Trash, it behaves the same whether 
the folder is viewed or unviewed (name bolds, no green arrow); but for non-Trash 
folders being viewed, the name is not bolded; it only gets the arrow.  If a 
non-Trash folder is *not* being viewed, it bolds and gets the arrow.

This is closely related to the behavior described in bug 179556.
Status: UNCONFIRMED → NEW
Ever confirmed: true
mass re-assign.
Assignee: naving → sspitzer
Assaf Lavie, this bug appears to have been fixed in the 0507 build; could you 
try with 1.4b?  Please mark this bug WorksForMe, if it does.
I was mistaken in my comment 9; probably I forgot to switch to Classic theme 
before testing.  Confirming that this bug still exists in
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
I'm also very annoyed by this bug, and I'm running a nightly build
(Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5b) Gecko/20030908)

I have a special folder called "SpamBox" where everything is caught that is
99.8% spam. But now my domain has been Hijacked by some other who's obviously a
victim of a spam-virus that sends off spams with my domain forged in the spam
mails, I want to delete all bounced messages and mark them as read.

But moving them to trash AND marking them as read doesn't work.
Marking them ONLY as read does work, but leaves the message in my inbox.

I don't care about the green arrow on my mailbox (so I know that there is at
least mailbox activity), as long as I am not specially alerted or the whole
trash box is displayed in bold letters, because I will always spend my time
looking what new spam or bounces have gotten in my mailbox.
Nina Cording, when you set up the filter to Mark Read and Delete (or, Mark Read 
and Move to Trash), these are the symptoms for this bug:  Trash folder is bold; 
Trash folder does not include updated of message count; messages within Trash 
are not bold (read).  Does that match your observation?

Are you using the Classic theme?  If so, try using another theme, Modern or a 
theme based on Modern like Orbit or Pinball.  If not Classic, please state which 
theme you are using.

Suppressing the new mail notification (system tray icon) for messages that are 
marked read is bug 206050 (and may be addressed by a patch under development for 
a different bug, see bug 189289 comment 64); suppressing the notification for 
messages filtered to Trash is bug 91498.
I just can't use any other theme than the classic theme.
Since Version 1.5b, other themes don't work anymore.
It's sad, because I really loved that pinball theme.

Maybe I need an updated theme for 1.5b
Maybe that's again a bug and I don't know the workaround
The built-in Modern theme should still be useable.  Other themes, yes, we need 
to wait for updates from the authors of Pinball, Orbit, Skypilot, etc.

I started thinking about why this bug appeared to be theme-dependent, and dug 
into the Modern and Classic jar files (in the Mozilla/chrome directory).  I 
think I've found the critical difference between the two themes:  in
    Classic.jar::skin/classic/messenger/folderPane.css
are these lines:
  treechildren:-moz-tree-cell-text(folderNameCol, newMessages-true),
  treechildren:-moz-tree-cell-text(folderNameCol, specialFolder-Inbox,
      newMessages-true) {
    font-weight: bold;
  }

There is no corresponding rule in Modern.jar's corresponding file.  I rebuilt 
the JAR with a version of that file omitting those lines, and voilà, could no 
longer duplicate the bug.

The rules that are used to bold the foldername in Modern are duplicate in 
Classic:
  treechildren:-moz-tree-cell-text(closed, subfoldersHaveUnreadMessages-true) {
    font-weight: bold;
  }

  treechildren:-moz-tree-cell-text(folderNameCol, isServer-true),
  treechildren:-moz-tree-cell-text(hasUnreadMessages-true) {
    font-weight: bold;
  }

Note the difference between 'hasUnreadMessages-true' and 'newMessages-true'.

I don't know why the newMessages-true rule is in place.  It appears to be 
designed to bold the Inbox, and folders in general, for new-but-read messages.
But, if this behavior is undesirable, you can work around it the same way I did; 
just be aware that this hack needs to be repeated after every reinstall.
*** Bug 227428 has been marked as a duplicate of this bug. ***
i am getting this bug with firebird also. in addition i get the new mail
notification in my system tray (win 2k). as stated this is v annoying as it
makes the whole purpose for such a filter unattainable, as junk still get my
attention. my vote goes here.
Still an issue under 0.7. This is the one thing that **** me off about this
product. This issue occurs for around 30% of the mail i recieve as all the
emails generated by me in our bug tracking system are automatically deleted and
marked as read. several times a day thunderbird tells me i have new mail and i
click the notification only to find it's in the trash. I'm sure it's not a very
hard thing to do and judging by the number of similar bugs logged it's obviously
in high demand. thanks for reading my rant ;)

some related open bugs:
Bug 107206 - dupe?
Bug 220933 - similar
Bug 202341 - similar
Bug 211439 - related
Bug 157115 - related
Note that the oddball symptoms in comment 7 no longer occur (in 1.7a builds).  
With the Classic theme, filtering a message by Deleting (into Trash) or Marking 
Read and Moving to any folder, will cause that folder to appear bold but without 
changing the displayed number of unread messages -- whether or not the 
destination folder is being viewed.  (The inconsistency was cleared by the fix 
for bug 192039.)

The bolding is a result of the style-rules detailed in comment 14, and appears 
when the folder itself has a New flag.  Bug 230805 has been filed about the New 
flag being set on a folder that receives only marked-as-read (and therefore, Not 
New) messages.  Once that bug is fixed, those style rules in the Classic theme 
won't make any difference.


Paul Stanton, none of the bugs you mention pertain to this bug, which is a 
pretty minor display fluke and has nothing to do with notification; your primary 
complaint would, I think, be solved by fixing bug 206050.
Summary: messeges deleted by filter are 'unread' in trash → messages deleted by filter are 'unread' in trash
Whiteboard: [see comment 14]
I am using 1.7 under Windows 2000.  I experience this bug with both the Classic
and the Modern themes.  I have a rule set up to delete the message and mark it
as read, but when it arrives, it goes to the trash folder, which becomes bolded
and shows the number of unread messages, and when I go to it, it has a green
arrow (in the Modern theme) and is bolded.

I am using IMAP.  I have two IMAP accounts set up.  Mozilla/5.0 (Windows; U;
Windows NT 5.0; en-US; rv:1.7) Gecko/20040616

If I edit the filter and set it to Move to folder Trash instead of delete, it
accepts it, but when I go back to edit the filter, it shows the default
(non-folder pulldown menu for my first account), and it does not move it to Trash.  

It also still fails if I write to filters, one, run first, to mark it read, and
one, run afterwards, to delete it.


(In reply to comment #19 [Eric Ewanco])
> I am using 1.7 under Windows 2000.  I experience this bug with both the
> Classic and the Modern themes.  

Then your problem is NOT THIS BUG.


> I have a rule set up to delete the message and mark it as read, but when
> it arrives, it goes to the trash folder, which becomes bolded and
> shows the number of unread messages, and when I go to it, it has a green
> arrow (in the Modern theme) and is bolded.
> 
> I am using IMAP.

IMAP has several possible ways of handling "delete" -- you can see the options 
in the Account Properties, Server Settings page.  The behavior you are seeing is 
a result of using the "Move to Trash" action (at least, that's what I see with 
my IMAP account on fastmail.com -- other IMAP servers may behave differently).

I don't see a bug for this particular problem, altho there are quite a few 
Networking:IMAP bugs with 'delete' in the summary.  Feel free to open a new bug 
for this problem.


> It also still fails if I write [two] filters, one, run first, to mark it read,
> and one, run afterwards, to delete it.

The behavior is not completely identical, tho: with this configuration, you 
should see that when you select the Trash folder, the message does get marked as 
read immediately, and has no New flag (green arrow).  But the folder does indeed 
bold and increment the Unread count until that point.


> If I edit the filter and set it to Move to folder Trash instead of delete, it
> accepts it, but when I go back to edit the filter, it shows the default
> (non-folder pulldown menu for my first account), and it does not move it to
> Trash.

I don't see either of these symptoms; a filter with Move to <imapaccount>/Trash 
works as expected, and on re-editing displays as expected.  If you can reproduce 
this, open a new (separate) bug for it.  (Note that unless the filter also Marks 
As Read, you will get a notification when the message is Moved to Trash.)
Dear mcow,

I apologize if I erroneously associated my symptoms with this bug.  As a
software development engineer who works with bug reports daily, I understand the
importance of clearly identifying symptoms and carefully reporting bugs.  So I
have tried to be very careful in reporting this.  I am sorry if I failed in that
goal.

It would be helpful to know specifically why you believe this is "NOT THIS BUG".
 I suspect you are keying in on the fact that the log indicates that it cannot
be reproduced with the Modern theme.  Surely you appreciate the fact that 1)
"cannot be reproduced" is not equivalent to "fixed"; 2) ten months is plenty of
time for a regression to occur?  In other words, the fact that someone could not
reproduce the bug in September 2003 using the Modern theme does not, in my mind,
rule out the possibility that I am seeing this same bug.  

Have you tried to reproduce the bug in the *same build* I am using with both the
Classic theme and the Modern theme?  That might tell us useful information.

In any case, if I am to file a new bug, because I do not clearly understand why
my bug is different from this one, you will need to provide me with sufficient
information to distinguish my new bug from this bug, so that it doesn't get
marked as a duplicate, and I have another engineer yell at me.  Thank you.

Eric
We need some clarification on this bug.

Assaf Lavie posted the bug.  These are the symptoms he reported: Messages appear
unread and bolded in trash folder; trash folder is in bold characters; trash
folder has number of unread messages increased in the label.

Nina Cording replied, reporting the same symptoms, except she did not
*explicitly* say whether she saw the number of unread messages in the Trash
folder increase.

In Comment 12, Mike replied.  He asked Nina if these are the symptoms she sees:
Trash folder is bold; trash folder does NOT include updated message count;
messages within trans are NOT bold (read).  This contradicts the symptoms
originally reported by Assaf on two points.

Finally, Nina never confirmed these symptoms Mike summarized, and neither did Assaf.

My symptoms are the symptoms reported by Assaf.  They are not the symptoms Mike
reported in Comment 12.  

Does this bug pertain to the symptoms reported by Assaf and Nina, or summarized
by Mike?  I don't care which, but for the sake of posterity, it should be stated
unambiguously that the bug with these symptoms is NOT being tracked here, and
that the bug with those symptoms ARE being tracked here.

Thanks.
Mike has opted to bow out of this bug.  I appreciate the time he has put into it.

At this point I'd like to propose that we clarify that the bug being tracked has
the symptoms reported by Assaf (who opened it):

When messages match a filter configured for both Delete (or Move to Trash) and
Mark as Read, and the Delete action is configured as Move to Trash,

1) Messages appear unread and bolded in Trash folder; 
2) Trash folder is in bold characters; 
3) Trash folder has number of unread messages increased in the label.
So I'm looking in nsImapMailFolder.cpp, in ApplyFilterHit, and there is a line,
under the Delete case and if (deleteToTrash) if, that has the comment "Mark read
in trash", but the code is commented out.  Was this intended to be checked in,
perhaps due to a conflicting bug, or was it accidental?
Apparently this line was commented out in Version 1.621 by bienvenu, "fix 232892
imap unread counts not correctly updated when moving messages from imap to imap,
sr=mscott". But this fix was February 2004; as of April of 2003, when this bug
was submitted, the line was uncommented.  So there must be another cause of the
bug, although I am curious if there is a story about this line that bienvenu
could tell that might shed some light on the problem.
I believe that line was removed because we now automatically mark messages read
when they're deleted, at the imap protocol level, i.e., we store the /SEEN flag
with the /DELETED flag, in the source folder.

But, that's just for the source folder, not the destination folder. And since we
do the copy followed by the delete, the destination read status won't be
affected either way.

The way this should be working, if you have two filter actions, one to mark the
message read, and one to delete the message, is that the mark read action runs
first, and marks the message read in the source filter; then the delete/move to
trash action runs, and copies the already marked read message to the trash. It's
really up to imap to maintain the /SEEN flag when the message is copied. 

I'll give this a try and see what happens.
should be fixed by checkin to bug 243832
Assignee: sspitzer → bienvenu
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.