Using oct16 branch build Seen on linux and win98, assume mac Read news messages appear unread after exit and return. 1. Open a newsgroup, read some messages. 2. Exit, return and open that newsgroup again. Result: messages previously read now appear unread. Note: if you mark all messages read, returning will preserve those messages' read status. Seen in most cases, although in some instances on Stephen's windows profile all was OK.
Seth, I hate to pull you off of the performance work you are doing for compose, but this could have potential 094 impact. The only changes that have gone into news in the last month were your changes to fix a problem with messages showing up as read for servers requiring auth. I don't think that could have triggered this bug but maybe I'm wrong. Can you take a look?
Seth pointed out that this sounds like a dup of 103824. However, David said that bug was caused by a checkin he made to the trunk only. Very odd.
One thing to note: my commercial branch Win32 build works just fine, but I share profiles with my Mozilla debug/opt build.
what platform do you see on then Stephen?
Linux and OS X 10.1 weren't working for me today on the branch.
Yes, I have the same problem on OS X on the branch build. The profile I have was created on Oct 4 and it's never been used on trunk or Mozilla builds. I've used 6.1 on this same profile.
Seth is looking into this. He has an explanation for the problem. We have a timer that goes off every 5 minutes which writes out to the newsrc file messages you recently marked as unread. If I wait 5 minutes before quitting after I read a news article and I restart, that message IS marked as read. Seth thinks we may be leaking our news server which has code on shut down to force us to write out to the newsrc file and to kill this timer. i.e. to reproduce this problem you have to quit within 5 minutes of the last news article you marked as read.
PDT-, the workaround is that user should not quit before 5 minutes after reading the first message.
here's what I think is going on. if you exit and there are change that haven't been written out, we rely on shutdown, which closes all the connections, which will write out the newsrc file if it is dirty. bienvenu found a problem where shutdown observers might be skipped, and this is probably it. see bug #101143 for his fix. that fix is trunk only, and was not applied to the branch. here's the stack trace from where newsrc writing occurs when the observer isn't skipped: nsNntpIncomingServer::WriteNewsrcFile(nsNntpIncomingServer * const 0x03a4e188) line 368 nsNntpIncomingServer::CloseCachedConnections(nsNntpIncomingServer * const 0x03a4e120) line 433 + 16 bytes nsMsgAccountManager::closeCachedConnections(nsHashKey * 0x03a4fdb0, void * 0x03a4e120, void * 0x00000000) line 1059 _hashEnumerate(PLHashEntry * 0x03a4fd70, int 0x00000000, void * 0x0012fa34) line 198 + 26 bytes PL_HashTableEnumerateEntries(PLHashTable * 0x02ccd380, int (PLHashEntry *, int, void *)* 0x10029240 _hashEnumerate(PLHashEntry *, int, void *), void * 0x0012fa34) line 429 + 15 bytes nsHashtable::Enumerate(int (nsHashKey *, void *, void *)* 0x027171f0 nsMsgAccountManager::closeCachedConnections(nsHashKey *, void *, void *), void * 0x00000000) line 371 + 21 bytes nsMsgAccountManager::CloseCachedConnections(nsMsgAccountManager * const 0x02ccd320) line 1421 nsMsgAccountManager::Shutdown() line 190 nsMsgAccountManager::Observe(nsMsgAccountManager * const 0x02ccd324, nsISupports * 0x00485350, const unsigned short * 0x0012feb4, const unsigned short * 0x00000000) line 222 nsObserverService::Notify(nsObserverService * const 0x0053a890, nsISupports * 0x00485350, const unsigned short * 0x0012feb4, const unsigned short * 0x00000000) line 238 NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 465 main(int 0x00000004, char * * 0x00485c60) line 1640 + 8 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903()
since this is PDT-, I'm marking it as a dup of #101143, which is fixed on the trunk. *** This bug has been marked as a duplicate of 101143 ***
marking verified as a duplicate, seems to work fine now on the oct26 trunk build.
removing item for this bug from mozilla 0.9.6 release notes since the bug this is duplicated against is now fixed