If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

After reading news messages, next session they appear unread again.

VERIFIED DUPLICATE of bug 101143

Status

MailNews Core
Backend
--
major
VERIFIED DUPLICATE of bug 101143
16 years ago
5 years ago

People

(Reporter: laurel, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

Trunk
mozilla0.9.6

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT-])

(Reporter)

Description

16 years ago
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.
(Reporter)

Updated

16 years ago
Keywords: nsbranch
QA Contact: esther → laurel

Comment 1

16 years ago
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?
Assignee: mscott → sspitzer
Target Milestone: --- → mozilla0.9.6

Comment 2

16 years ago
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.

Comment 4

16 years ago
what platform do you see on then Stephen?
Linux and OS X 10.1 weren't working for me today on the branch.

Updated

16 years ago
Whiteboard: [PDT]

Comment 6

16 years ago
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.

Comment 7

16 years ago
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. 

Comment 8

16 years ago
PDT-, the workaround is that user should not quit before 5 minutes after reading
the first message.
Keywords: relnote
Whiteboard: [PDT] → [PDT-]
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 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 11

16 years ago
marking verified as a duplicate, seems to work fine now on the oct26 trunk build.
Status: RESOLVED → VERIFIED

Comment 12

16 years ago
removing item for this bug from mozilla 0.9.6 release notes since the
bug this is duplicated against is now fixed
Product: MailNews → Core
Product: Core → MailNews Core
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.