In the last few days I've noticed some strange new behavior with Thunderbird. Automatic timed message retrieval recognizes that there are new unread messages in a folder and displays the number of them in the sidebar correctly, but the new messages are not displayed in the message list. Switching to another folder and back doesn't fix the problem. Nor does compacting the folder. But right-clicking on the folder, selecting Properties, and clicking on "Repair Folder" causes the new messages to appear correctly. This happens on both POP and IMAP accounts. This happens with great frequency, but not consistently. After repair, new messages will appear correctly for a while, but within a short period of time the problem reoccurs. As I say, this is extremely recent behavior (no more than two weeks old).
I've seen this only once, a few weeks ago, when I had a very bad internet connection. I assumed the bad internet connection caused it. Do you see nothing odd, while this happens, if you ping those pop and imap servers? If not: do you keep having the same problem when installing Thunderbird-52.2.1 from upstream? https://www.mozilla.org/en-US/thunderbird/all/
CC: (none) => marja11Assignee: bugsquad => doktor5000Keywords: (none) => NEEDINFO
According to the crawl tooltips at the bottom of TB, it has not had any problem connecting to the servers when this happens. Plus, TB is finding out that there *are* messages and how many. I hesitate to pollute the system with an upstream version, but I'll keep that in my back pocket. I haven't seen this for a couple of hours now, and I noticed that a "Filter messages by..." input that I had previously placed on a different folder persisted to the Inbox on a different server. While I didn't notice the affected folder's contents being filtered, this could have prevented the new messages from displaying. Previously, filter input disappeared when switching folders within an account, much less across accounts. I cleared this, so we'll see. If this does persist, I'll have to capture a damaged index file in some sort of controlled scenario on a test ID which can be compared with the repaired index file. I'm not really crazy about using my live Inbox index files as diagnostics.
That was it. The behavior of filtering was changed so that the filter string doesn't get cleared *ever*. I can understand why this would prevent new unread messages being displayed if they didn't pass the filter, but not why Repair pulled them in, since Repair doesn't clear the filter string either.
Status: NEW => RESOLVEDResolution: (none) => INVALID
I'm curious if you're using a Gmail account when you see these problems. 52.2.1 specifically fixes Gmail issues.
(In reply to David Walser from comment #4) > I'm curious if you're using a Gmail account when you see these problems. > 52.2.1 specifically fixes Gmail issues. Nope. The POP server is my ISP's, and the IMAP server is my employer's. If it's of any interest, the filter string was "TRA", which seemed to match an awful lot of stuff, making the cause non-obvious.