287833 - New mail indicators don't update in subfolders

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Alan Batie]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Both at work and home, my mail is on imap servers.  Both at work and home, I
have mozilla running to read mail from both servers.  Mozilla at home files my
personal mail and Mozilla at work files my work mail.  The Mozilla that didn't
file the mail never notices that subfolders have new mail unless those folders
are touched.  Likewise, I have sieve doing some of the filing, actually
intending for it to be the primary filer eventually, but in that case no Mozilla
would ever notice the subfolders with new mail.  I would like at least the
option to have it check all folders for new mail when it's doing its checking...

Reproducible: Always

Comment 1

[R.K.Aa.]

Is 'Check this folder for new messages' checked?

Comment 2

[Alan Batie]

I thought I already replied to this, but it seems to have gotten lost...

I hadn't even noticed there was a properties menu on the folders.  I suppose it
makes sense, but I would then change this request to adding the options from the
properties to the New Folder menu.

Also, and maybe this is a separate issue:

1.  Copy a set of messages from INBOX to a folder.  At least some of them are
unread.
2.  Right click on the destination folder and Mark as Unread.

The box will be "opened" (wasn't it opened to put the message *in* it?) and the
unread messages will stay unread.  You have to mark unread a second time to get
it to take, and actually, sometimes that doesn't do it either.  Sometimes you
have to actually click on the folder and let it build the index to be able to
mark it unread, though I'm not certain it's not just me being impatient and not
waiting long enough for background threads to catch up.  FWIW...

Comment 3

[Patrick]

regression, as this was fixed in bug 186894.

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #3)
> regression, as this was fixed in bug 186894.

David, is this a regression as suggested above?  Or is this a different issue?

And, what is 'Check this folder for new messages' all about?  Does it work
differently for "subscribed" folders?  Why isn't it on by default? 

Comment 6

[David :Bienvenu]

this is a different issue - that bug was only about check for new mail in other
folders at startup.

"Check this folder for new messages" polls IMAP folders besides the INBOX for
new messages, mostly because some folks have server side filters moving messages
into other imap folders automatically. The reason it's not on by default is that
very few users need or want this; for other users, it would just be adding
unneccesary load to the imap server.

I don't really understand the separate issue - is the reader talking about mark
as read, instead of mark as unread? If so, yes, that makes sense that we'd need
to download the headers before we'd mark the messages read, though we could and
should special case mark all read in imap so that we didn't have to do that.

Comment 7

[Alan Batie]

Ooops, you're right: Mark as Read --- what an odd dyslexia for me to get!  While
you may have to download the headers to do it, the bug is that it stops there
--- it doesn't go ahead and mark them as read like you told it to until the
second time you right click/Mark as Read.