51813 - New threaded messages aren't marked read when displayed.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

[scottputterman]

Steps to reproduce:

1.  make sure the folder is in threaded mode.
2.  Send yourself a message.
3.  Get that message and reply to it.
4.  Get that message and display it.
5.  Notice that it isn't marked read, the New status stays and it is still bold.
 You can't even click the green diamond to change the state.

Comment 1

[scottputterman]

nominating for beta3.  It seems like it would be hard to use threads if this is
the case.  I noticed this on Imap.

Comment 2

[selmer (gone)]

[nsbeta3+]

Comment 3

[scottputterman]

cc'ing waterson.

I think this may be happening in RDF code.  I've stepped through the code and it 
looks like it's notifying the RDF observers correctly of any changes.

The bug is this:

If you are in threaded mode and have a message:

A

and then reply to A such that when you do GetMessage you have

A
  B

then when you click on B, it will not become marked read. The status won't 
change, the boldness won't change, you can't click on the green diamond or on 
the flag.  The mailnews backend seems to be working fine at the db level and the 
notifications to make these changes seem to make their way fine to the RDF level 
at which point RDF says there are no modifications after trying to find a Match.

Comment 4

[scottputterman]

reassigning to waterson.

Comment 5

[Chris Waterson]

Yes, this was a bug in nsXULTemplateBuilder; more problems from the menu hackery
that hyatt and I put in back in r1.196 or so. Attaching a patch...

Comment 6

[Chris Waterson]

Attachment: proposed fix

Comment 7

[Chris Waterson]

What hyatt and I did in r1.194 or so was wrong: we messed around with a MatchSet
directly. I've re-constified a bunch of methods to make it harder for me to mess
up like that again.

The meat of the fix here is to realize that InstantiationNode::Propogate()
doesn't need to remember the "new" keys. It is only called in one of two ways:

1. By nsXULTemplateBuilder::CreateContainerContents(), which will "seed" the
rule network with the container element and expect *all* matches related to that
container to be returned, or

2. By nsXULTemplateBuilder::Propogate(), which will seed the rule network with
the new RDF assertion that's arrived, and will thus only instantiate matches
related to that assertion.

rjc, putterman: I'm a bit scared by this change, so if you guys could try it out
and let me know if you see anything weird, I'd appreciate it!

Comment 8

[scottputterman]

Thanks for fixing this.  I need to update my tree but I'll try to either try it 
out tonight or tomorrow morning.

Comment 9

[scottputterman]

I played around with this yesterday and it seemed to be working.

Comment 10

[Robert John Churchill]

r=rjc too

Comment 11

[Chris Waterson]

fixed

Comment 12

[fenella]

Linux (2000-09-18-06 M18)
Win32 (2000-09-18-08 M18)
Mac (2000-09-18-08 M18)
This problem has been fixed.