Last Comment Bug 787186 - Thunderbird clears news feed display window and list when refreshing feeds
: Thunderbird clears news feed display window and list when refreshing feeds
Status: RESOLVED FIXED
: regression
Product: MailNews Core
Classification: Components
Component: Feed Reader (show other bugs)
: 15
: x86 Mac OS X
: -- major (vote)
: Thunderbird 19.0
Assigned To: alta88
:
Mentors:
: 769501 802556 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-30 12:50 PDT by WD
Modified: 2012-11-15 23:57 PST (History)
8 users (show)
ryanvm: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
fixed
fixed


Attachments
Feed subscription set that demonstrates the problem (17.64 KB, text/plain)
2012-08-31 12:35 PDT, WD
no flags Details
Full console2 log when windows cleared refreshing engadget (2.59 KB, text/plain)
2012-09-01 11:14 PDT, WD
no flags Details
Screenshots of fresh launch vs. 60 seconds later (336.07 KB, image/png)
2012-09-02 09:39 PDT, WD
no flags Details
patch (3.45 KB, patch)
2012-10-21 12:15 PDT, alta88
standard8: review+
standard8: approval‑comm‑aurora+
standard8: approval‑comm‑beta+
Details | Diff | Splinter Review

Description WD 2012-08-30 12:50:13 PDT
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

Actual results:
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.

Expected results: 
Checking for new feed entries should not mess with any of the window panes, as Thunderbird did with version 14 and earlier.
Comment 1 alta88 2012-08-31 07:06:04 PDT
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.
Comment 2 WD 2012-08-31 11:15:14 PDT
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.
Comment 3 alta88 2012-08-31 11:44:05 PDT
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.
Comment 4 WD 2012-08-31 12:14:16 PDT
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
Line: 634

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)
Comment 5 WD 2012-08-31 12:35:50 PDT
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.
Comment 6 alta88 2012-08-31 13:08:05 PDT
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.
Comment 7 WD 2012-08-31 20:52:12 PDT
How does one obtain the entire log?   I can only see options to copy individual entries.
Comment 8 WD 2012-08-31 21:41:10 PDT
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.
Comment 9 WD 2012-09-01 08:34:31 PDT
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
Line: 634
Comment 10 alta88 2012-09-01 09:28:31 PDT
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.
Comment 11 WD 2012-09-01 09:52:10 PDT
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.
Comment 12 WD 2012-09-01 11:14:19 PDT
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.
Comment 13 alta88 2012-09-01 14:20:32 PDT
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.
Comment 14 WD 2012-09-02 09:39:11 PDT
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.
Comment 15 WD 2012-09-02 09:59:39 PDT
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.
Comment 16 alta88 2012-09-02 12:44:08 PDT
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).
Comment 17 WD 2012-09-02 13:05:57 PDT
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.
Comment 18 Sean Smith 2012-09-11 10:32:14 PDT
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.
Comment 19 Pouya K 2012-10-09 14:21:43 PDT
This happens to me, too. Gentoo with Thunderbird 15. Thunderbird <=14 was fine.
Comment 20 alta88 2012-10-17 14:54:54 PDT
*** Bug 802556 has been marked as a duplicate of this bug. ***
Comment 21 PapaJaac 2012-10-17 22:01:03 PDT
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.
Comment 22 alta88 2012-10-21 12:15:50 PDT
Created attachment 673719 [details] [diff] [review]
patch

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.
Comment 23 Pouya K 2012-10-21 17:11:36 PDT
(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. 

Thanks!
Comment 24 Pouya K 2012-10-22 22:11:02 PDT
Patch seems good in Thunderbird 16 as well.
Comment 25 Ryan VanderMeulen [:RyanVM] 2012-11-06 14:35:02 PST
https://hg.mozilla.org/comm-central/rev/d7737df4bfd5
Comment 26 alta88 2012-11-07 08:30:12 PST
Comment on attachment 673719 [details] [diff] [review]
patch

[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.
Comment 27 PapaJaac 2012-11-12 01:13:49 PST
Hi,

I don't understand recent messages. Could you please tell me in what TB version this problem will be fixed ?
Thank you.
Comment 29 Ludovic Hirlimann [:Usul] 2012-11-12 04:18:45 PST
(In reply to PapaJaac from comment #27)
> Hi,
> 
> 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.
Comment 30 Dan Stillman 2012-11-15 23:57:36 PST
*** Bug 769501 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.