Closed Bug 14028 Opened 21 years ago Closed 21 years ago

message counts not getting updated


(Core Graveyard :: RDF, defect, P3)

Windows NT


(Not tracked)



(Reporter: Bienvenu, Assigned: hyatt)



In the folder pane, message counts are not getting updated, though we are
changing the right property, as near as I can tell. Here's a stack trace deep in
the bowels of RDF...
(I'm not sure if this is a generic RDF problem, or should be filed as a
mail/news bug - feel free to change it, and let me know what I can do to help)

  XULDocumentImpl::AttributeChanged(XULDocumentImpl * const 0x028c27c0,
nsIContent * 0x0323d0f0, nsIAtom * 0x00f60b10, int -1) line 2138
  RDFElementImpl::SetAttribute(RDFElementImpl * const 0x0323d0f0, int 0, nsIAtom
* 0x00f60b10, const nsString & {...}, int 1) line 2433
  RDFGenericBuilderImpl::SynchronizeUsingTemplate(nsIContent * 0x031c6870,
nsIContent * 0x0323d0f0, RDFGenericBuilderImpl::eUpdateAction eSet,
  nsIRDFResource * 0x021c1e50, nsIRDFNode * 0x039fea50) line 1968
  RDFGenericBuilderImpl::SynchronizeUsingTemplate(nsIContent * 0x031c5390,
nsIContent * 0x0323da00, RDFGenericBuilderImpl::eUpdateAction eSet,
  nsIRDFResource * 0x021c1e50, nsIRDFNode * 0x039fea50) line 2010 + 47 bytes
  RDFGenericBuilderImpl::SynchronizeUsingTemplate(nsIContent * 0x031c5df0,
nsIContent * 0x03238f90, RDFGenericBuilderImpl::eUpdateAction eSet,
  nsIRDFResource * 0x021c1e50, nsIRDFNode * 0x039fea50) line 2010 + 47 bytes
  RDFGenericBuilderImpl::OnAssert(RDFGenericBuilderImpl * const 0x031bf5a4,
nsIRDFResource * 0x0267bc90, nsIRDFResource * 0x021c1e50, nsIRDFNode
  * 0x039fea50) line 1078 + 42 bytes
  CompositeDataSourceImpl::OnAssert(CompositeDataSourceImpl * const 0x031bf554,
nsIRDFResource * 0x0267bc90, nsIRDFResource * 0x021c1e50,
  nsIRDFNode * 0x039fea50) line 1243
  nsMsgRDFDataSource::assertEnumFunc(nsISupports * 0x031bf554, void *
0x0012fa44) line 378
  nsSupportsArray::EnumerateForwards(nsSupportsArray * const 0x026789a0, int
(nsISupports *, void *)* 0x01b37ca0
  nsMsgRDFDataSource::assertEnumFunc(nsISupports *, void *), void * 0x0012fa44)
line 352 + 20 bytes
  nsMsgRDFDataSource::NotifyObservers(nsIRDFResource * 0x0267bc90,
nsIRDFResource * 0x021c1e50, nsIRDFNode * 0x039fea50, int 1) line 363
  nsMsgFolderDataSource::NotifyPropertyChanged(nsIRDFResource * 0x0267bc90,
nsIRDFResource * 0x021c1e50, const char * 0x039feca0, const char *
  0x039fec50) line 766
Target Milestone: M11
Chris, I wouldn't mind pitching in and looking some more at this one...Do you
mind? Do you have any advice?
from you stack trace, it looks like the info is getting propogated into layout
correctly. at which point, the tree widget may be dropping it on the floor. if
you can, grab hyatt and make him sit in your cube to fix this :-)

addressbook has a very similar bug that i suspect is a dup.
Blocks: 14779
Assignee: waterson → hyatt
Hyatt has checked in a fix. I'm going to try it, and if it works, mark it fixed
for him.
Bad news.  It did not work on my machine.  My method never even gets called,
which makes me think there may also be a bug in RDF or something.
Bummer, I'll try it out on my machine.
Find out what the content node is that's being passed in on the
AttributeChanged.  It had better be a <treecell>.  If it isn't, RDF is to blame.
You may be seeing an artifact of a performance change Scott and I made. If you
were expecting to get called when opening the folder, you won't. But marking a
message read or unread should change the counts.
Closed: 21 years ago
Resolution: --- → FIXED
Sweeeet! it works!
Awesome! Thanks a lot, Dave. Scott or I will fix the problem updating the
message counts after folder loading.
adding myself to cc: list.
QA Contact: tever → lchiang
Lisa, can your team verify this? Thanks.
QA Contact: lchiang → chuang
candice has kindly offered to help verify bugs.
Verified on 1999-12-13-09-M12 Win32 build, 1999-12-13-08-M12 Mac build and
1999-12-13-08-M12 Linux build.  Message counts are updated when opening folder,
read message, delete message, mark read/unread.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.