64480 - mark all read fails on messages gotten with "Get Next <x> News Messages"

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[(not reading, please use [e-mail] instead)]

get 100 messages from a newsgroup
mark all read, they get marked
get next 100 using "Edit | Get Next 100 News Messages".
those next 100 come is as read.  mark a few of then as unread.
mark all read, those last few you marked as unread don't get marked read.

related to what is causing #64476?

Comment 1

[Andreas Premstaller]

I still can reproduce this using 2001121103 on W2K.
If I mark a few messages as unread after "get next n news messages"/"mark as
read", the unread message count in the folder pane goes up as it should. If I
now "mark all read", then the folder turns from bold to normal in the folder
pane, unread message count goes to 0 (not displayed anymore), but the messages
in the thread pane remain marked as read. If I now change to another newsgroup
and then go back to the first one, the messages are marked as read.

Comment 2

[David :Bienvenu]

taking, fix upcoming

Comment 3

[David :Bienvenu]

Attachment: proposed fix

the problem here is that nsNewsDatabase::MarkAllRead uses the low water mark
for the start of the range, but that's incorrect if you do a Get Next NN
messages. The fix is to use the known arts set to determine the low water mark.
I've also fixed the known arts set to use a cstring since it will always be a c
string. I've also added code to store the current state of the read set for a
news db when a db is commited (this will be used for another bug fix, but it's
harmless for now).

Comment 4

[(not reading, please use [e-mail] instead)]

Comment on attachment 82141 [details] [diff] [review]
proposed fix

sr=sspitzer

Comment 5

[David :Bienvenu]

fix checked in.

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

Verified FIXED with builds:

Mac OS X 10.1.4 - 2002-05-24-08
RedHat 7.3 - 2002-05-25-07
Windows 2000 - Current self-built trunk

I'd like to see this land on the branch - since I've verified it, and it seems
harmless (no regressions found so far).  Nominating.

Comment 7

[scottputterman]

I think we can wait until the next release for this one.