User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:184.108.40.206) Gecko/20091206 SeaMonkey/2.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:220.127.116.11) Gecko/20091206 SeaMonkey/2.0.1 From time to time a few read emails suddenly get marked as unread again. This occurs since Seamonkey version 2.0.0. Reproducible: Sometimes Steps to Reproduce: I am using *one* IMAP account containing a number of subfolders (about 20). About half of them I have configured as "Check this folder for new messages", the others not. 1. In a given folder containing multiple mails (10 to 1000 for me), memorize which mails are still unread. Now do one of the following: A. File: Offline: Download/Sync Now... (I have checked only "Mail Messages") B. File: Compact Folders C. File: Get new messages Note: Choice A has by far the highest probability to produce the problem. 2. Sometimes you need to change the selected mail folder back and forth in Seamonkey Mail main window, to get the wrong result displayed. 3. Notice if some read mails have been marked as unread again. This happens randomly, no tendency towards newer/older mails or else can be noticed. Never has an unread mail become marked as read for me. 4. If you experience the garbled read/unread markers, then exiting and restarting Seamonkey does NOT rectify the problem. 5. Doing a "Rebuild Summary File" per affected folder (in "Properties" context menu) ALWAYS rectifies the read/unread markup! Expected Results: Read/unread marker remains unchanged by Download/Sync or Compact Folders.
Rebuilding the index seems to rectify the problem for me as well. However, this also resets the visible columns to the default view (which I think is complete overkill)
Does your IMAP server support CONDSTORE extension? Read thru bug 517461 and Get IMAP log and check flow, please. > https://wiki.mozilla.org/MailNews:Logging Can your problem be re-produced even with Seamokey trunk laest nightly build? > http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/
See also bug 524902.
My IMAP server is Dovecot 1.2.8 and supports CONDSTORE: -1328291840[1f9ce350]: 1826ca00:<deleted>:NA:CreateNewLineFromSocket: 1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in
I am using IMAP at the mail service provider FastMail.FM and they support CONDSTORE: 660[3f40580]: 51f4800:mail.messagingengine.com:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ COMPRESS=DEFLATE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN DIGEST=SHA1 IDLE URLAUTH SASL-IR AUTH=PLAIN
Note: FastMail.FM states they are using Cyrus IMAP/POP server see https://www.fastmail.fm/help/technology_fastmail_technology.html
Bug 524902 is a perfect description of the problem. I tried turning off condstore support - see https://bugzilla.mozilla.org/show_bug.cgi?id=517461#c9 Turning off condstore resolves my problems.
Further tests (all with mail.server.default.use_condstore set true): Seamonkey 2.0.2 problem persists Seamonkey 2.1a1pre en-US.win32 (build 12-Jan-2010 10:18) problem resolved!
Closing as FIXED to keep seamonkey2.1a1 in "Target Milestone:".
As written in Bug 524902 Comment #36, patch for Bug 524902 will be landed on 1.9.1 branch also for Tb 3.0.1. If possible, check with nightly of Sm 2.0.x(1.9.1 branch) after landing of the patch, please.
I'm not a developer. How do I know if the patch for Bug 524902 has been landed on 1.9.1 branch? Seamonkey 2.0.3pre en-US.win32 (build 14-Jan-2010 02:23) problem persists! As usual, turning off condstore resolves my problems.
(In reply to comment #11) > As written in Bug 524902 Comment #36, patch for Bug 524902 will be landed on > 1.9.1 branch also for Tb 3.0.1. If possible, check with nightly of Sm > 2.0.x(1.9.1 branch) after landing of the patch, please. The solution for this bug did not land in TB 3.0.1 It does appear to be solved in the nightly builds though.