285144 - Unread flag removed on parent folder even if other subfolders still have unread messages if ONE subfolder changes to no more unread messages

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Michael Nüsken]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.6) Gecko/20050226 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.6) Gecko/20050226 Firefox/1.0.1

A mail folder is marked in bold if it contains unread messages or a folder that
contains unread messages.  I am working with a server that distinguishes
subfolder folders (directories as pine callas them) and message only folders,
don't know whether this is important.
If now one subfolder changes from "contains unreads" to "contains no unread"
also the parent folder changes to contains NO unread EVEN if there are other
subfolders  that still have unread mails.

Reproducible: Always

Steps to Reproduce:
1. Go to a folder that has at least two subfolders with unread mail.
2. Go to one of the subfolders and read all unread mail in it.  Leave at least
one other subfolder with an unread mail.
3. Close the parent folder.

Actual Results:  
The parent folder is not marked as having unread mail under it any more.

Expected Results:  
The parent folder should be flagged as long as there is some subfolder contains
an unread mail.

Comment 1

[Mike Cowperthwaite]

I see this, and I'm not having any luck finding a dupe.
Reproduced with TB 1.0+0303 and Moz 1.8b-0303, Win2K.

Comment 2

[Flavio Stanchina]

This is a dupe of bug #276650

Comment 3

[John David Galt]

*** Bug 276650 has been marked as a duplicate of this bug. ***

Comment 4

[David :Bienvenu]

the problem is here:

http://lxr.mozilla.org/mozilla/source/mailnews/base/src/nsMsgFolderDataSource.cpp#1734

This needs to be changed to force a recalculation of this attribute, not forcing
it off. I'll try to figure out how to do that.

Comment 5

[David :Bienvenu]

Attachment: proposed fix

see comments in diff. The one thing I'm not sure about is if I should do this
w/o a comptr - I suppose I could just pass in &aNode and do an NS_RELEASE after
the call to createHasUnreadMessagesNode (which addrefs the result). But the
comptr does the same. The folder data source holds a ref to the true and false
literals, so we don't have to worry about it going away when the comptr goes
out of scope...if we were worried about that, we could duplicate the calls to
notify property changed and notify ancestor changed inside the scope of the
comptr...

Comment 6

[Worcester12345]

Just found this bug. I always just figured this is how it was meant to be.