Open Bug 162475 Opened 22 years ago Updated 2 years ago

Wrong Biff/"new mail notification" when messages are moved to IMAP folder with "Check this folder for new messages" option or user pref "mail.check_all_imap_folders_for_new"

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

People

(Reporter: stupiddog, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

I want to check all my IMAP folders for new mail, so I use the 

user_pref("mail.check_all_imap_folders_for_new", true);

entry in my prefs.js. I have an IMAP/SSL account which is checked for new mail
regulary (every 10 minutes). Sent mail is put into another IMAP folder within
the same account, like the following structure:

Account
  |- INBOX (<-- new mail comes here)
  |- SentMail (<-- sent mail is put here)
  |- Another Folder...

When I compose a new mail and sent it, I get a "Andreas.Buschka has 1 new mail"
message the next time Mozilla checks for new mail. This did not happen with
Mozilla 1.0+. This is pretty annoying since I have to open my mail & news window
and go the SentMail folder to remove the icon the the windows tray bar.
Another problem:

If you have specified a special folder within that IMAP account to which deleted
messages should be moved, the following problem occurs:

1. Go to a random folder and delete some messages, say 10.
2. Wait for mozilla to check for new mail.

Expected Result: No "Andreas.Buschka has new messages" message
Actual Result: "Andreas.Buschka has 10 new messages".
which build are you using?
...already tried to create a new profile?
(are you using your 1.0+ profile with your current build?)
I am using Mozilla 1.1 Beta (the beta release build, not a daily one). Yes, I
have already tried a new profile.
I get this with 1.1 final release. 1.0 was fine.  It makes the 'new mail'
message, which was useful, meaningless.
(I'm using Windows 2000, IMAP mail)
The same with 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

As to profile it seems to came from previous time but IMAP account is freshly
created.

I use Cyrus IMAP server with alternative namespace, i.e. special folders such as
'Sent', 'Drafts' and 'Trash' reside at the same level of hierarchy as 'INBOX'
do. On my opinion these spesial folders should be excluded from list of folders
that are checked for updates.
One more obsevation. Deleting message (i.e. putting it into Trash), filing
message in certain folder also couses new message notification. For example, I'm
reading newsgroup and then store certain message in IMAP folder. And
notification arises in spite of the fact that message is marked as read. It
seems that during the check amount of messages or some other criteria are
checked instead of checjing the read/unread status. So I believe that new
message that comes as read should not make  notifikation.
This happens when I delete mail (which automaticly moves it to the trash folder)
or when I manually move mail between folders.  MailNews will later report that
there is new mail, place a green arrown on the account but fail to indicate in
which folder to "new" mail resides.  

I've seen this for many weeks now but have been too lazy to file or find the bug
report.  I'm doing that now and have found several candidates.  I sure I will be
dup'ing this or several other bugs soon.

I believe that although the complains and proposed remedies are different, the
root cause of this bug and bug 156830 are the same.

Bug 156830 suggests that MailNews should indicate which folder has "new" mail. 
(I dissagree)

This bug suggests that no new mail notification should occur at all under such
circumstances.  (I agree)

It would be best to argue the merits of both remedies under a single bug.


*** Bug 156830 has been marked as a duplicate of this bug. ***
*** Bug 158196 has been marked as a duplicate of this bug. ***
*** Bug 119647 has been marked as a duplicate of this bug. ***
*** Bug 165838 has been marked as a duplicate of this bug. ***
> This bug suggests that MailNews should indicate which folder
> has "new" mail.  (I dissagree)

I have filters on my mail server that categorize email messages and store them
into different folders.  If MailNews didn't indicate which folder has new mail I
would no longer be able to use it.
6e77a 70 6e 6e7a,

From what I understand, the "mail.check_all_imap_folders_for_new" pref is now
depricated.  You can now achieve the same functionality through the UI:  Just
right clicking over each folder for which you want new mail notification. 
Select "Properties." In the "General Information" tab, chechmark the "Check this
folder for new messages" option.  MailNews will now indicate whether or not the
folder has new mail. (Bug 156830 should have been resolved as invalid.)

The real issue here is that new mail notification should only happen when truly
new messages arrive ... but not when exsisting messages (read or unread) are
moved from folder to folder.  In your case the new mail notification should go
off because the messages are truly new regardless of whether they are filered or
not from the inbox to another folder.  In my case, when I run a filter that move
exsisting messages between folders, delete exsisting mail, or manually move
exsisting mail from one folder to another, the new mail notification should
*not* go off.

I hope this clears thing up.  If I'm mistaken, please let me know.
Okay,  I've given some thought to this.

The new/non-new status of mail needs to be calculated at the account level.
Messages should be marked as "new" from the time they first arrive in the
account to the first time they are read or marked as read.  Note that "unread"
does not equal "new"!  A read message can be remarked as unread but it's non-new
status should remain the same. This new/non-new status should be preserved even
when the message is moved from folder to folder just as the read/unread status
of messages is preserved.  Folders should display the "contains new mail"
indicator based only on the new/non-new status of the messages it contains
regardless of whether any message happens to be new or not to the folder itself.
 Likewise, *new mail notification (biff: "<account name> has XX new messages")
should only go off when "new/fresh/unseen-before" new-status mail arrives in the
account.*

For the most part, the above mirrors the current behavior of the read/unread
status of messages and its corresponding folder indicators.  Whatever logic (not
"code" but "logic"!) is being used to manage the read/unread status should also
be used to manage new/non-new status.

Question's for spin-off bugs:

1) Per-folder biff's ("<account name> has XX new messages in <folder name>")

If an RFE doesn't yet exist for this, I'm sure one will soon. Should this biff
go off only when new status mail (new account-level mail) is moved into the
folder or when any message that is new to the folder (new folder-level mail)
appears?  (I'm not confident in my gut feeling that the former should prevail
since it preserves the read/unread status model I've been following but what
about manual filter runs on existing mail???)

2) Moving messages between accounts

Currently, read messages moved between accounts remain read.  Following this
model, should non-new messages remain non-new when moved between accounts? 
(Maybe the fact that read messages moved between accounts remain read should be
considered a bug.  If so, non-new messages should become new when moved between
accounts.)

Okay, that's my $12.99 analysis of the situation.  I hope I haven't ticked off
anyone ... just wanted to help.
Summary: Wrong "You have new mail" messages when using mail.check_all_imap_folders_for_new → Wrong Biff/"new mail notification" when messages are moved to IMAP folder with "Check this folder for new messages" option or user pref "mail.check_all_imap_folders_for_new"
I really like the approach described in comment #15. If done correctly, it might
also fix bug 174395 -- "Folder has new messages" mark should survive restart (or
crash).
Blocks: 174395
QA Contact: huang → gchan
*** Bug 191978 has been marked as a duplicate of this bug. ***
#183377 is a duplicate of this bug

The summary is quite complicated, not easy to find.
*** Bug 183377 has been marked as a duplicate of this bug. ***
Hi All,

I've given my tupence worth in bug 183377, but I'd like to add something here.

Ian, In comment 15, you talk about moving message between accounts.

I would suggest that a read email in one account should not be considered read
or new when moved to another account. This is something I do every day (I have
work and home IMAP accounts, but sometimes emails get misdirected (usually due
to me picking the wrong account when sending!!!) and need to be moved about.

Also, I have a procmail system to filter my regular contacts such that the email
for them goes into their own folder. This rule applies to incoming and outgoing
emails that I've BCC'ed to myself. When these BCC'ed emails appear in the
contacts folder (or by default into the Sent folder if no matching contact is
found by procmail), this triggers a new mail notification. The folder is not
highlighted as procmail marks the BCC'ed messages as read (the folder indicator
is really just "how many unread messages in this folder, right?).

So the folder indicator and the new mail indicator (the green icon in the
mozilla quick launch area (bottom left) and the system tray under windows) are
not as tandom as you seem to make out. Perhaps I'm missing something.

But anyway, my BCC'ed mails that come in, in my opinion, should not trigger a
new mail notification, regardless of which folder they go into (i.e. don't treat
Sent as a special case, as it could be *any* folder).

I think I see the need for some new account-prefs.

[ ] Treat incoming but read mail as new.

And new general mail prefs
[ ] Preserve read status between accounts.


If the former option above is implemented, how do you mark which folder that
message is in? As I said above, the folder marker is (AFAIK) just an indicator
of how may *unread* messages are in a folder. If an incoming mail is marked as
read (by procmail), how do you flag the folder. Perhaps Mozilla should
automatically mark it as unread? But thinking about it, when Moz borks on a
folder and redownloads the headers, this may have the effect of marking them all
as unread, which is obviously not desired.

Having written the above and thought about it, I'm increasingly of the opinion
that if a message is marked as unread, then just ignore it....

For what it's worth, I think the Unread mail indicator is useful as it stands.
If this were replaced by a new/un-new indicator, I think that would be a step
backwards (have I understood you wrong in comment 14 Ian, where you say
<QUOTE>Folders should display the "contains new mail"
indicator based only on the new/non-new status of the messages it contains
regardless of whether any message happens to be new or not to the folder
itself.</QUOTE> - besides, I disagree with this due to my BCC self setup - I
don't want to be told 5 mins after I send a mail that I have a new message, I
/know/ I'll have a new message, but I want to ignore it!!)

Hope this helps the discussion. I may be inaccurate in several areas, or have
too custom a setup to be helpful, but hopefully not!

Col.
Blocks: biff
Collin,

I'm not sure if you quite understand what I'm suggestion.  Right now there are
*two* separate indicators in mozilla mailnews and thunderbird, one for unread
mail and another for new mail.  Using the Modern theme in the latest build of
Mozilla and the classic theme in thunderbird, the unread mail indicator takes
the form of bolded folder names and message headers while the new mail indicator
takes the form of a green down arrow (Mozilla) or orange star (thunderbird)
superimposed over folder and envelope icons.

I'm not suggesting that the new mail indicator should replace the unread mail
indicator or that the unread indicator should be changed in anyway.  I agree
with you that the unread indicator is perfectly fine as it stands.  It the green
arrows and orange stars that are not behaving as many would expect and it is
only that behaviour and the accompanying new mail notification that I would like
to see refined.  

I can appreciate how my suggestion might cause you some pain considering the way
you use bbc, however, I believe yours is a special case that would be best
addressed in a new bug.  IMHO, new mail is new mail even if it is a self-bbc'd
or marked-as-read-by-server.  Maybe a hidden pref like the one you suggested or
a mail extension could suppress new mail notification for such messages if the
user desires.

I'm an IMAP mail user and that may have influenced me to suggest that mail moved
between accounts should be marked as new.  With IMAP, mail stays on the server
and each mail account can reside on different IMAP server. In this environment,
dragging a message from one mail accounts to another will literally move the
message from one server to another and is a near equivalent of emailing the
message to the destination account.  Couple this with the fact that IMAP
accounts can be simultaneously shared by several user and one persons actions
can be seen by many.  For instance, if a co-worker drags a message into my
public IMAP account, I'd like that message marked as new.  This is *not* to say
that it should be marked as *unread*, only that is should be marked as new and I
should receive a new mail notification.  Similarly, if a third party were to
drag a message into a co-worker's public account that I am sharing, I'd expect
the message to be marked as new and be notified of its arrival.  (Whether the
messages should also be marked as unread is debatable.  At the moment, I'd say
"no".)  

I think that with an addition bug report, both your and my expectations can be
accommodated.
Isn't this bug a duplicate of bug 226885?  Or at least related to it?
Hi!

How can you test which folders are marked as "Check this folder for new
messages"? How does Mozilla record this? There is obviously no entry in the
pref.js file.
for #23:  right-click on folder, Properties..., checkbox for "Check this folder
for new messages"
For #24: OK, that's the GUI way. I should have mentioned that I wanted to
examine the user profile's files to check if a folder is marked or not.
I do not want to go to a user and have him check all his folders manually if
that flag is set. 
Regarding what this bug has ostensibly become about, per the summary: I see 
"wrong" notification in two cases: 
1) when a client-side filter moves a message into a checked folder.  In that 
case, I'm notified when the message arrives, and then again when I click on the 
destination folder; that second notification is unnecessary.

2) when a client-side filter marks a message read and moves it into a folder.  
In all cases, the destination folder gets a New flag (bug 230805), and it is 
bolded and its unread count incremented, despite the message having been marked 
read.  In Mozilla 1.7/1.8, this also causes a notification if the deletion model 
is Mark As Deleted and the destination is another folder in the IMAP account -- 
this is bug 257573.
(There are a couple of other oddball behaviors here, e.g. bug 254589.)


As for what this bug was originally about, I am not getting notifications on 
messages placed into the remote Sent folder, even if that folder has explicitly 
been configured with "check for new messages."



(In reply to comment #15)
> This new/non-new status should be preserved even when the message
> is moved from folder to folder just as the read/unread status of
> messages is preserved.  

"New" in Mozilla means "this message (or folder, or account) is (or contains) 
mail of which the user is not yet aware."  Mozilla does this imperfectly, but: 
if you've moved a message via a UI action, you're "aware" of its existence and 
it should no longer be New.  (If the message was moved with a filter, it remains 
New.)  I'd say this should be true even in the case of moving between multiple 
IMAP accounts.  The New flag is intended to be ephemeral: it should trigger 
notification and help you find the new mail after you've become aware of the 
notification.  It is not intended to persist.

There are cases where the action taken to "become aware" of the message is not 
really intuitive (esp bug 174395, which is blocked by this bug, incorrectly 
IMO), and there are also some bugs in the implementation, but that is the model.



(In reply to comment #21)
> I agree with [Collin] that the unread indicator is perfectly fine as it
> stands.  It [is] the green arrows and orange stars that are not behaving as
> many would expect 

You mean, "as I would expect," of course.  I presume you haven't taken a survey 
to justify that "many."

> I believe [Collin's self-BCC scheme] is a special case that would be best
> addressed in a new bug.  IMHO, new mail is new mail even if it is a self-bbc'd
> or marked-as-read-by-server.  

It may be new, but it's not worth being notified about.  There are quite a few 
bugs about suppressing notification in cases that people don't care about: Junk 
(bug 189289), mail that's been filtered to the trash (bug 91498) or marked read 
(bug 206050), and items put into the Sent folder (the original symptom of this 
bug).  Also bug 11040 is about putting direct control of the notification into 
the filter mechanism.


> Couple this with the fact that IMAP
> accounts can be simultaneously shared by several user and one persons actions
> can be seen by many.  For instance, if a co-worker drags a message into my
> public IMAP account, I'd like that message marked as new... and I
> should receive a new mail notification.

This is a reasonable expectation.  I don't know what the technical details are 
(specifically, I don't know exactly how or whether Mozilla's New and Unread 
states are mapped to IMAP's /RECENT and /SEEN); but for this to work as desired, 
Mozilla's New state needs to be decoupled from the server's message state.  At 
any rate, if Mozilla/TB do not do what you expect in this case (I can't test, 
having only one completely private IMAP account), then you should open a new bug 
for this issue.
Assignee: mscott → bienvenu
Product: MailNews → Core
Product: Core → MailNews Core
QA Contact: grylchan → networking.imap
I'm seeing this issue (or a similar issue?) as well, but I can't really distinguish between items 1 and 2 in Mike's comment. Let me describe what I'm seeing:

I'm using Gmail IMAP. I have a client-side filter on a mail client moving messages between folders - but not on my machine, on a different one. On the machine on which I'm seeing this issue, the folders with 'check for new messages' get emboldened when new messages arrive, but also on every subsequent check - repeatedly, regardless of whether there are new messages or not.
potential complication to doing bug 289208
Depends on: 289208
Assignee: dbienvenu → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.