When Thunderbird checks for new news feed articles, it clears the window that is displaying the current feed entry, as well as the feed entry list above it.
Steps to reproduce:
1) Configure Thunderbird to check for news feeds every minute
2) Click on a subscribed news feed and display an entry
3) Wait for Thunderbird to refresh feeds
Current feed window and the list of feed entries above it go blank. The only way to get it back seems to be to click on another feed and then go back to the original one.
Checking for new feed entries should not mess with any of the window panes, as Thunderbird did with version 14 and earlier.
this doesn't happen for me on either win7 or linux. threadpane selected message and messagpane content remain the same, on get new messages, whether there are new messages (added to top or bottom or threadpane per sort) or not.
1. does it happen repeatedly on the same folder, even after reselection?
2. other feed folders?
3. reproducible with all extensions disabled?
4. on a clean profile?
you can also set feeds.logging.console to debug (or even trace) and see if there is anything interesting in the error console.
I've only been able to reproduce the bug on OS X and Linux. Windows XP seemed ok. For what it's worth, I tested Debian Squeeze and OS X Lion. It may only happen when feeds have new entries, as opposed to just the act of checking.
It happens on the same folder repeatedly, and it happens on other folders. It happens on clean machines that have never had thunderbird or any other software installed on them. (so clean profile and extension questions are irrelevant)
The only thing I'm seeing in the feed logging is:
2012-08-31 13:16:18 Feeds ERROR downloadFeed: error - URIError: malformed URI sequence
I'm not sure which feed is causing that error, or perhaps it's just a red herring. I'm also not sure if it's something specific to the set of subscriptions that I've got either.
there is something corrupted/inaccessible about your feed folder(s). perms?
when Tb feeds processing detects it can't get at a folder's .msf (database) file it will rebuild it. this leads, necessarily, to the folder being closed/list being cleared. it's the same as doing a rt click, Properties, Repair Folder. usually, selecting a folder rebuilds an unavailable .msf on the occasion there's an issue.
the logging would tell you what folder and feed url the error belonged to if you had debug on. it may or may not be relevant.
Given that it's a fresh install on a clean OS, I can't see how that could be the situation. The only thing I've done is import the OPML file from my main system, so that the feeds are the same.
As for the debug logging, I was looking in the wrong place. (The terminal from which TB was launched, as opposed to the error console). I think I've narrowed it down to an offending feed, though. The two relevant errors from the console are:
2012-08-31 14:59:25 Feeds DEBUG downloaded: Update errorCode:feedName:folder - 0 : xorl %eax, %eax : /home/fuzz/.thunderbird/4gsjuj0j.default/Mail/Feeds-1/xorl %eax, %eax
Timestamp: 08/31/2012 02:59:25 PM
Error: malformed URI sequence
Source File: chrome://messenger-newsblog/content/utils.js
But alas, it seems to be a red herring. Even after removing the offending feed subscription, the blanking problem still happens. It's looking like this may take a bit of trial and error to narrow it down. (Assuming it is indeed related to one of the feeds)
Created attachment 657398 [details]
Feed subscription set that demonstrates the problem
I've attached a feed subscription set that reproduces the problem. So if anybody is at least trying to reproduce the bug, import that set, set TB to refresh feeds every 1 minute, view a feed entry, and sit back and wait. I've reproduced with Linux and OS X.
hmm, no issues on linux mint. the xorl etc foldername blows up the pretty print (malformed uri) but no list clearing.
a rebuilt folder (list cleared) will be logged as
downloadFeed: rebuild msgDatabase for ...
post the log around there.
How does one obtain the entire log? I can only see options to copy individual entries.
I just downloaded Linux Mint and installed it in a VM, unpacked the Thunderbird 15 tarball, imported my opml, and it reproduced pretty quickly. I'm not sure what else I can provide to demonstrate how to reproduce the bug. It seems to not matter, but for what it's worth, I was viewing a message in the "Immovable Feast" feed when the blanking occurred. It seems that you may have to wait until a new article is ready in one of the feeds, so it may not be guaranteed to happen in 60 seconds.
Here's an example set of debug log entries for the xorl feed (which contains a % in the title). Note that the xorl blog is not the only one that triggers the bug. But it seems to do so more consistently/quickly. This was from a Debian system. DebianFuzz in particular, not that it should make any difference: https://www.cert.org/download/bff/d.html
2012-09-01 11:29:54 Feeds DEBUG downloadFeed: START x/# foldername:uri - 1/3 Blogs & News Feeds:mailbox://nobody@Feeds
2012-09-01 11:29:54 Feeds DEBUG downloadFeed: START x/# foldername:uri - 2/3 xorl %eax, %eax:mailbox://nobody@Feeds/xorl%20%25eax%2C%20%25eax
2012-09-01 11:29:54 Feeds DEBUG downloadFeed: CONTINUE foldername:urlArray - xorl %eax, %eax:https://xorl.wordpress.com/feed/
2012-09-01 11:29:54 Feeds DEBUG downloadFeed: DOWNLOAD feed url - https://xorl.wordpress.com/feed/
2012-09-01 11:29:54 Feeds DEBUG downloadFeed: START x/# foldername:uri - 3/3 Trash:mailbox://nobody@Feeds/Trash
2012-09-01 11:29:54 Feeds DEBUG downloadFeed: Finished with folder - Blogs & News Feeds
2012-09-01 11:29:54 Feeds DEBUG Feed.onDownloaded: got a download - https://xorl.wordpress.com/feed/
2012-09-01 11:29:54 Feeds DEBUG FeedParser.parseFeed: type:url - RSS_2.0 : https://xorl.wordpress.com/feed/
2012-09-01 11:29:54 Feeds DEBUG FeedParser.parseAsRSS2: channel nsURI -
2012-09-01 11:29:54 Feeds DEBUG Feed.invalidateItems: for url - https://xorl.wordpress.com/feed/
2012-09-01 11:29:54 Feeds DEBUG FeedParser.parseAsRSS2: items to parse - 10
2012-09-01 11:29:55 Feeds DEBUG Feed.removeInvalidItems: for url - https://xorl.wordpress.com/feed/
2012-09-01 11:29:55 Feeds DEBUG downloaded: Update errorCode:feedName:folder - 0 : xorl %eax, %eax : /home/fuzz/.thunderbird/hmmtbe9i.default/Mail/Feeds/xorl %eax, %eax
Timestamp: 09/01/2012 11:29:55 AM
Error: malformed URI sequence
Source File: chrome://messenger-newsblog/content/utils.js
first, there is a bug in constructing the pretty name iff there is a % in the folder name. so rename that folder.
there is no indication the folder was rebuilt. did this log run correspond to a list clear? doubtful, but maybe it matters that you're doing it in a vm.
i can't reproduce this, on linux, with your list, % and all. having a folder and message selected, waiting for a new refresh, watching various folder counts increase, including the selected one, leaves the threadpane selection/messagepane content untouched.
if you install the console2 extension, you will be able to do select all and multiselect. maybe use trace too.
Yes, that log run did correspond to a list clearing. If there's a bug where Thunderbird can't handle a '%' in the folder name, then perhaps it shouldn't create one that has that character in it? (You get it automatically by just subscribing to https://xorl.wordpress.com/feed/ ... no need to import the opml file) Perhaps a separate bug should be filed for that?
But anyway, the feed containing a % isn't required to reproduce this bug. You may just have to be more patient. In my testing, regardless of which feed is subscribed to, Linux / OS X will *eventually* clear the two right frames. You just have to wait.
Created attachment 657584 [details]
Full console2 log when windows cleared refreshing engadget
This is the full log file from Thunderbird launch until windows cleared. The only feed subscription is to Engadget.
i'll fix the % thing.
however, that log shows normal feed processing, and the feed subsystem didn't rebuild the folder. my linux Tb15 ubuntu build has gone through hours of 1min refreshes and the same selected Engadget folder and message are still there, and a few more have popped in.
you mention it works on winxp. can't even venture a haphazard theory. maybe someone will corroborate.
Created attachment 657688 [details]
Screenshots of fresh launch vs. 60 seconds later
Eh, I can't explain it either. Possibly even some sort of race condition or other non-deterministic behavior, potentially affected by CPU or network speed even? Not sure if it helps, but I've attached an image that compares screenshots of before and after the blanking. The only difference between the left and right is that I waited about 60 seconds for the right to occur. I suppose my best bet here is to hope that *somebody* else can reproduce it.
I've just verified that the feeds.logging.console debug log is identical between blanking and non-blanking refreshes. So some other source of logging is probably required.
hmm, it may have something to do with the fact you have only a feed account. there are other wierdnesses in such a case. try creating a mail or news account.
or try turning the quickfilter bar off (though it wfm with it on).
Eh, I first ran into the issue on my host OS (OS X Lion), which has several email accounts, so that's not a factor. I only have narrowed it down to the simplest configuration to try to eliminate other variables. Linux Mint or Ubuntu live CD (among others). Thunderbird 15 tarball extracted. Single rss feed subscribed to.
QuickFilter bar turned off doesn't help.
I had this happen to me using a recent Daily build, but so far only on Fedora 17 KDE. The folder it happened to is one with a feed that I have had setup since I installed Fedora 16 on the machine right after it was released, so it's got some age to it. Happened twice, once before applying that day's update and once after restart (since Tb checked the feed on start). Switching folders and back showed the messages again.
This happens to me, too. Gentoo with Thunderbird 15. Thunderbird <=14 was fine.
*** Bug 802556 has been marked as a duplicate of this bug. ***
Sorry for duplicate 802556. My OS is Mandriva Linux 2010.2 x86_64, and I use downloaded 64b TB.
I agree with Pouya K, TB <= 14 was fine.
Created attachment 673719 [details] [diff] [review]
i've been able to observe this. rather than a long treatise on msgDatabase or why its getter should fail for an account folder, a patch will be more useful.
(In reply to alta88 from comment #22)
I tried this patch on Thunderbird 15 and it seems to work great.
On gentoo I just copied it to
/etc/portage/patches/mail-client/thunderbird/ and re-emerged thunderbird.
Patch seems good in Thunderbird 16 as well.
Comment on attachment 673719 [details] [diff] [review]
[Approval Request Comment]
Regression caused by (bug #): bug 711173.
User impact if declined: regression remains.
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): very low. aside from the regression, 2 more rare but visible UX errors are fixed here.
I don't understand recent messages. Could you please tell me in what TB version this problem will be fixed ?
(In reply to PapaJaac from comment #27)
> I don't understand recent messages. Could you please tell me in what TB
> version this problem will be fixed ?
> Thank you.
17 whihc is currently in Beta.
*** Bug 769501 has been marked as a duplicate of this bug. ***