Launchpad has imported 28 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=693204.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-10-09T21:07:22+00:00 John Park wrote: User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1 Steps to reproduce: When reading an email or emails on another device/location, those emails are marked as read on that device and the IMAP server. I am using gmail & an IMAP connection on both Thunderbird and the other device. Actual results: When Thunderbird is left open, it sometimes takes 2-3 hours or even longer for Thunderbird to mark those emails as read. I have tried clicking on the "Get Mail" button to refresh the IMAP folder but TB still doesn't mark those emails as read. I have checked to see whether those emails are flagged as read or unread but using the gmail web client and they are indeed being marked as read but Thunderbird will not refresh their read/unread status. Expected results: Each time Thunderbird attempts to get mail it should check the status of read and unread emails from the IMAP server and mark those emails as read if applicable. The only way to force TB to refresh the read/unread status is to completely close TB and re-open which is obviously very annoying. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/30 ------------------------------------------------------------------------ On 2011-10-10T11:09:28+00:00 M-wada-7 wrote: Do you enable IDLE command use? If yes, same problem as bug 512745. bug 512745 : Gmail Label of A and B is added to a mail, and has flag \Seen(or no \Seen). The mail is shown in both Gmail IMAP folder named A and B, and Tb knows flag \Seen(or \no \Seen) of both mails. Mail in Gmail IMAP folder named A is changed to no \Seen(or has flag \Seen). Mail in Gmail IMAP folder named B is also changed to no \Seen(or has flag \Seen) at Gmail IMAP server, because both are copy of same mail each other. This flag status change at Gmail IMAP folder named B is not notified to IMAP client like Tb via IDLE. Your report : A mail in a Gmail IMAP folder has flag \Seen(or no \Seen). Tb1(or Smart Phone etc.) and Tb2 knows flag \Seen(or \no \Seen) of the mail. The mail is changed to no \Seen(or has flag \Seen) by Tb1(or Smart Phone). The flag status change at Gmail IMAP folder is not notified to Tb2 via IDLE. These are same phenomenon. > I have checked to see whether those emails are flagged as read or unread > but using the gmail web client and they are indeed being marked as read > but Thunderbird will not refresh their read/unread status. If the mail is "a mail in a conversation of Gmail which contains multiple mails", phenomenon of bug 478996 occurs. Don't use "read/unread status of a conversation at Gmail Web interface" as evidence of "read status or unread status of a mail", unless it's sure that the conversation of Gmail has single mail only or that all mails in a conversation of Gmail has same status of read or unread. See also bug 518581, if Gmail IMAP. > Expected results: > Each time Thunderbird attempts to get mail it should check the status of read > and unread emails from the IMAP server and mark those emails as read if > applicable. > The only way to force TB to refresh the read/unread status is > to completely close TB and re-open which is obviously very annoying. To avoid excess network traffic due to "fetch of flags of all mails in IMAP folder upon each folder access", (imagine 1,000,000 mails in a folder * 10,000 folders, new mail check of all mails folders each one minute) Tb currently relies on "flag status change notification from server via IDLE", but many IMAP servers including Gmail IMAP unfortunately don't look to do so. Following is a possible workaround at Tb in your case, if your any IMAP folder is never huge. - Disable IDLE command use Max chached connections = 1 (I think Smart Phone's setting is similar to: no IDLE, max=0) (Tb doesn't permit max=0. Always uses default of 5 if max=0 is specified) - When you want to know flag status change by other IMAP cilent, or when you want to know flag status change propagation to same mail in other Gmail IMAP folder, click different folder, then click needed folder at folder pane of Tb. Can you see flag status change by other IMAP client like Smart Phone, using Tb without restart? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/31 ------------------------------------------------------------------------ On 2011-10-10T20:08:31+00:00 John Park wrote: I tried disabling IDLE and setting max cached connections to 1 but there appeared to be no change to the issue. I also changed max cached connections to 0 and still no change. I tried selecting multiple folders (Sent Items, Drafts etc) to try and force TB to refresh the read flags within the Inbox folder but no joy. Interestingly, if I read an email in TB, that email is almost instantly flagged as read on my iPhone. There is still a delay of many hours if I read an email on my iPhone or web client to be marked as read in TB. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/32 ------------------------------------------------------------------------ On 2011-10-10T20:34:47+00:00 John Park wrote: Just noticed your notes regarding max cached connections = 0 not being a valid option. Changed back to 1 and still no change in result. The only way I can get TB to check for read/unread status is to exit TB and relaunch. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/33 ------------------------------------------------------------------------ On 2011-10-11T00:08:22+00:00 M-wada-7 wrote: (In reply to John Park from comment #2) > I tried disabling IDLE and setting max cached connections to 1 but there > appeared to be no change to the issue. Did you restart Tb after the setting change? Effect by the setting change is not immediate, so restart of Tb is needed to see effective or not. (In reply to John Park from comment #3) > Just noticed your notes regarding max cached connections = 0 not being a > valid option. Changed back to 1 and still no change in result. Read next in my comment, please. > (Tb doesn't permit max=0. Always uses default of 5 if max=0 is specified) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/34 ------------------------------------------------------------------------ On 2011-10-11T00:11:17+00:00 John Park wrote: I've restarted TB and it appears the emails are now being marked as read. Thank you for your help! Is this an issue with TB or google? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/35 ------------------------------------------------------------------------ On 2011-10-11T00:14:21+00:00 Mozilla-ex wrote: It's an issue with how google handles synchronizing state between multiple connections. It's up to the server how frequently it does that synchronization... Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/36 ------------------------------------------------------------------------ On 2011-10-11T00:38:32+00:00 M-wada-7 wrote: (In reply to John Park from comment #2) > Interestingly, if I read an email in TB, that email is almost instantly > flagged as read on my iPhone. Is this true for a mail in other than Inbox? At Tb, move(not copy) some(not one) mails from Inbox to other than Inbox (call Test folder, not subfoler of Inbox) At iPhone, see the mails in folder named Test. At iPhone, see other folder than the Test folder, such as Inbox. At Tb, show "Order Received" column of Test folder. At Tb, change Read/Unread status of a mail in Test folder which has smallest "Order Received" column value. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/37 ------------------------------------------------------------------------ On 2011-10-11T03:02:43+00:00 M-wada-7 wrote: Per folder setting like next may be a solution. [ ? ] When automatic new mail check is invoked for this folder, always checks flag/keyword status of all mails in this folder. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/38 ------------------------------------------------------------------------ On 2012-01-29T05:44:02+00:00 M-wada-7 wrote: *** Bug 568775 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/39 ------------------------------------------------------------------------ On 2012-01-31T00:58:22+00:00 Doublehp wrote: Tagging the old report as dup of the new one is the best way to make devs think the bug is recent (and irrelevant). Yes, an other TB3 profile on the same host. But bug can also be reproduced with any other Imap client, like my mobile phone: just after reading an email on Gmail, I can sync my phone, and it will show mail as read; but clicking GetMail on TB3 will now ... untill TB restart. This is making 568775#c6 irrelevant. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/40 ------------------------------------------------------------------------ On 2012-01-31T00:59:48+00:00 Doublehp wrote: An other point against TB, prooving that it's not Google's fault: bug appeared during the week after migration from TB2 to TB3 ... it would be a very strange hasard if Google changed their server conf just that week ... Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/41 ------------------------------------------------------------------------ On 2012-06-06T01:19:45+00:00 M-wada-7 wrote: FYI. Another workaround, if "max cached connections=1" is not practical in your environment, and if you are eager to know flag/keyword change of existent mails by other mail client even though your IMAP server doesn't notify flag/keyword change to Tb via IDLE : Go "Work Offline mode", then go back to "Work Online mode", and, if folder you want to know flag/keyword change by other is FolderX, click an account or other folder, then click FolderX. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/43 ------------------------------------------------------------------------ On 2013-12-05T09:39:21+00:00 M-wada-7 wrote: FYI. Gmail IMAP started to support CONDSTORE from this year, so problem in Tb's CONDSTORE support is perhaps exposed to all Gmail users(see bug 912216, bug 885220). IIUC, workaround of "Going offline then online" is affected by the problem and the workaround perhaps doesn't work as expected(see bug 885220 cmment #76). Disable Tb's CONDSTORE support, please. mail.server.default.use_condstore = false (setting for all IMAP accounts) mail.server.server#.use_condstore = false (per account setting) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/46 ------------------------------------------------------------------------ On 2013-12-05T10:04:35+00:00 M-wada-7 wrote: FYI. If server supports CONDSTORE, and if CHANGEDSINCE of CONDSTORE is used by Tb upon new mail check, problem of this bug can be resolved. 1. Upon first open(select at cached connection) of Mbox after restart. select "Mbox" (CONDSTORE) * OK [HIGHESTMODSEQ 120418] UID fetch 1:* (FLAGS) 2. Upon second or later open(select at cached connection) of Mbox after restart of Tb. select "Mbox" (CONDSTORE) * OK [HIGHESTMODSEQ 120418] UID fetch 1:* (FLAGS) (CHANGEDSINCE 120418) 3. Upon each new mail check at cached connection where Mbox is already selected. UID fetch 1:* (FLAGS) (CHANGEDSINCE 120418) * 836 FETCH (UID 3292 MODSEQ (120420) FLAGS (\Seen)) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/47 ------------------------------------------------------------------------ On 2013-12-05T10:11:40+00:00 M-wada-7 wrote: *** Bug 512745 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/48 ------------------------------------------------------------------------ On 2013-12-05T10:12:49+00:00 M-wada-7 wrote: *** Bug 518581 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/50 ------------------------------------------------------------------------ On 2013-12-05T10:13:36+00:00 M-wada-7 wrote: *** Bug 594106 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/51 ------------------------------------------------------------------------ On 2013-12-05T10:15:13+00:00 M-wada-7 wrote: *** Bug 672585 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/52 ------------------------------------------------------------------------ On 2013-12-06T05:55:42+00:00 M-wada-7 wrote: *** Bug 573985 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/53 ------------------------------------------------------------------------ On 2013-12-06T05:56:47+00:00 M-wada-7 wrote: *** Bug 606395 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/54 ------------------------------------------------------------------------ On 2013-12-06T05:59:18+00:00 M-wada-7 wrote: *** Bug 577586 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/55 ------------------------------------------------------------------------ On 2013-12-06T06:00:51+00:00 M-wada-7 wrote: *** Bug 650103 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/56 ------------------------------------------------------------------------ On 2013-12-06T07:08:24+00:00 William Paul wrote: Thanks for the information, WADA. The easy way to disable the CONDSTORE as suggested on Comment #13 is by doing this: 1. [On Linux] Edit -> Preferences // [On Windows] Tools -> Options... 2. Advanced -> Config Editor... 3. Search for "CONDSTORE" (with no quotes, and it shouldn't matter if it's lowercase). 4. Double-click on "mail.server.default.use_condstore" to change the 'Value' to "false". 5. Close the Config Editor (the search window). 6. Restart Thunderbird. I hope this works, as I am just trying this fix out myself. (See my old bug comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=594106#c43) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/57 ------------------------------------------------------------------------ On 2013-12-07T00:14:06+00:00 Nyet wrote: Again, disabling CONDSTORE does not always help. There should probably be two separate bugs, one for CONDSTORE related, one for not related to CONDSTORE.. a bunch of different bugs all got rolled into one bug, so if somebody fixes CONDSTORE, hopefully they will not close this :/ Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/58 ------------------------------------------------------------------------ On 2013-12-07T06:02:10+00:00 M-wada-7 wrote: (In reply to Nye Liu from comment #24) Nye Liu, please don't confuse following. (a) problem of this bug(notification of flag status change) (b) problems due to CONDSTORE support in Tb (c) Tb's behavior in CONDSTORE support which may affect on workaround of this bug; - Going Work Offline, going back Work Online, then re-open folder by folder click - max cached connection=1, re-open folder by folder click (d) A possible solution of this bug by utilizing CONDSTORE (by correctly using) "Disabling CONDSTORE support of Tb" in this bug is only for (c), even though the "disabling CONDSTORE support of Tb" is automatically applied to (b) always. Purpose of workaround of this bug is to force Tb to issue "uid fetch 1:* flags" upon "folder click" step in workaround. However, as I already pointed in comment #13, Tb may issue "UID fetch 1:* (FLAGS) (CHANGEDSINCE mod-seq-value)" or "uid fetch HighestUID:* (FLAGS)" upon the folder click in the workaround when CONDSTORE support of Tb is enabled. And, it may be different between Inbox and other Mbox. It may depend on timing of events during workaroud execution. Inconcistency of phenomenon during workaround execution surely produces user's confusions. Purpose of "Disabling CONDSTORE support of Tb" in this bug is: Surely force "uid fetch 1:* flags" upon "folder click" step of workaround. Avoid user's confusions during workaround execution. Because problem of this bug itslef is absolutely irrelevant to CONDSTORE support by Tb, even if CONDSTORE extension can be utilized to resolve problem of this bug, I'm sure that developers never confuse this bug with CONDSTORE support related problem. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/59 ------------------------------------------------------------------------ On 2013-12-07T09:22:45+00:00 M-wada-7 wrote: (In reply to Nye Liu from comment #24) > There should probably be two separate bugs, one for CONDSTORE related, one > for not related to CONDSTORE.. > a bunch of different bugs all got rolled into one bug, (snip) Nye Liu, have you actually read and understood all bugs which is duped to this bug by me? Which phenomenon in which dup'ed bug is not problem due to "flag status change is not notified from IMAP server via IDLE"? Do you actually understand problems by CONDSTORE support of Tb or problems in Tb around CONDSTORE? Have you read and understand Bug 885220　which I already pointed in comment #13, which is for problem occurs only when CONDSTORE support of Tb is enabled? Do you understand a change in the past which is one of causes of Bug 885220? Have you read and understand bug 885220 comment #88? Do you understand why the "change in the past" was backed out? Do you understand what problem may occur again by the backuot? Do you understand what problem occurred by the backout? Have you read and understand bug 912216 which I already pointed in comment #13? These problem relevant to "CONDSTORE extention and Tb's CONDSTORE support" and problem relevant to "flag status change is not notified from IMAP server via IDLE" are clearly isolated already. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/60 ------------------------------------------------------------------------ On 2013-12-08T07:53:28+00:00 M-wada-7 wrote: Quick summary of this bug, to avoid confusions by some peoples, or to avoid irrelevant comments due to confusion with problems in Tb's CONDSTORE support. -Problem of this bug; - Because server doesn't notify flag status change via IDLE, Tb can't know flag status change of mails at server Mbox via IDLE. - Tb's expectaion of "server notifies flag status change via IDLE" is never RFC violation, because "flag status change notification via IDLE" is SHOULD. - Server's behavior is never RFC violation, because "flag status change notification via IDLE" is SHOULD, is never MUST. - Unfortunately, some major IMAP servers don't notify flag status change via IDLE, and Gmail IMAP is an example of such server. - Problems in current "Tb's CONDSTORE suport" is irrelevant to above problem of this bug which is produced by IDLE command use. Please never confuse following. - If CODNSTORE extention is well utilized, problem of this bug can be resolved by simple method. - Current Tb's CONDSTORE support has some problems, so "disabling Tb's CONDSTORE" is better. Rather, Tb user MUST disable it until problems will be resolved, if Tb user uses IMAP server who supports CONDSTORE extension. - Gmail started to support CONDSTORE extesion this year, and Tb's default is mail.server.default.use_condstore=true. So problem in "Tb's CONDSTORE support" is exposed to Tb/Gmail IMAP user from this year. Because number of Tb+Gmail IMAP user is not so small, default of mail.server.default.use_condstore should be changed to false. "dup'ed bugs to this bug which is relevant to Gmail IMAP" was opened before Gmail started to support CONDSTORE extension. How can problem reported to these dup'ed bugs be relivant to Tb's CONDSTORE support and/or CONDSTORE extesion? - Because wrokaround of this bug is affected by CONDSTORE extension and Tb's current CONDSTORE support, Tb user who experienced problem of this bug should disable Tb's CONDSTORE support, if Tb user uses IMAP server which supports CONDSTORE, in ordre to make the workaround usable, in order to avoid confusion produced by problem in Tb's CONDSTORE support. - Because "disabling Tb's CONDSTORE support" does do nothing if IMAP server doesn't support CONDSTORE or server is not IMAP server, Tb user can disable Tb's CONDSTORE support freely, safely, any time, regardless of "used IMAP server supports CONDSTORE or not", regardless of "IMAP server is used or not". Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/603402/comments/61 ** Changed in: thunderbird Status: Unknown => Confirmed ** Changed in: thunderbird Importance: Unknown => Medium ** Bug watch added: Mozilla Bugzilla #594106 https://bugzilla.mozilla.org/show_bug.cgi?id=594106 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/603402 Title: Thunderbird incorrectly shows some Gmail archived messages as unread via IMAP To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/603402/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
