User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050716 SeaMonkey/1.0a Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050716 SeaMonkey/1.0a This is tricky. Mozilla/SeaMonkey/TB Nightlys set new downloaded messages after 5 minutes to read. Close and re-open Mozilla brings back the unread-marks. This messages now will no longer affected by this bug. Only new downloaded messages are affected. Mozilla don't set all messages at once to read. Exactly 5 minutes after you open the first new message, it take 2-4 Groups and set them to read. The next pack of groups follow after again 5 minutes. It stops when the last message is set to read. Its start in the next group with unread messages. The group you actually read is not affected. Reproducible: Always Steps to Reproduce: 1.set all messages as read. 2.close mozilla, re-open it and download some newsgroup messages 3.read the first message and then wait. Actual Results: after 5 minutes Mozilla starts setting newsgroups to status 'read' Expected Results: Mozilla should not set newsgroups to read This is not new. IIRC the bug started in June. The 5 minutes interval sometimes are going up to 10 minutes, but also can be shorter. I don't download news for offline reading in Mozilla. I use a local Mail/Newsserver(Hamster from http://tglsoft.de).
I could see this with a Win2k trunk build, too, thus confirming. I don't have simple steps to reproduce either (yet), but we can rule out Hamster (I don't have one) and maybe specific newsservers (it happened with news.mozilla.org for me). The time range for that happening for me is about 7-12 minutes.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have seen similar effects with my self compiled gtk2-builds on linux. Sometimes the status of a newsgroup ist set to read, this can be reverted by clicking on this group in the folderpane. Even clicking on a newsgroup with unread articles sometimes sets an adjacent newsgroup to read. Waiting is enough to revert the false read state. The length of the time to wait is undtermined, can be a few seconds to a few minutes. This happens only after a fresh start of my suite, but not always. Difficult to reproduce.
*** This bug has been marked as a duplicate of 298737 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.