705504 - Ensure feeds are deleted cleanly and completely.

Status: RESOLVED FIXED

(MailNews Core :: Feed Reader, defect)

Description

[alta88]

Attachment: fix.

some checks to catch errors and continue with feed deletion's many parts.  also immediately delete feeditems rather than bypass for the purge delay (once the feed is deleted it will never process).

this should eliminate a lot of resubscribe problems.

Comment 1

[alta88]

Attachment: fix2.

Comment 2

[Ian Neal]

Comment on attachment 577121 [details] [diff] [review]
fix2.

Just a drive-by on some of the comments in the patch.

>+  // Try hard to clear the folder's msgDatabase feedUrl property else
>+  // subscriptions dialog will forever have an empty ghost feed.  A
>+  // repair won't fix it, only a .msf file delete with Tb closed or
>+  // folder delete.
As this is shared code:
>+  // repair won't fix it, only a .msf file delete with the client
>+  // closed or a folder delete will.

>+  if (!msgdb)
>+    // Give up, although we could still call getDatabaseWithReparse with
>+    // listener..
Nit: this should either be a single full stop or three/an ellipse

Comment 3

[alta88]

is there any reason why the code is setting the feedUrl property via folder.msgDatabase.dBFolderInfo.setCharProperty()?  it seems like folder.setStringProperty() would be less brittle.  is the former more persistent than the latter, ie not affected by folder Properties->Repair eg.

the out of sync of feedUrl and feeds.rdf, and the many paths to get out of sync, is the biggest cause of turmoil in feed-land, imo.

Comment 4

[Alexander Kriegisch]

I have searched the bug database for a bug I had for as long as I can remember in many Thunderbird versions. Is the patch discussed here related to it and if so, will it fix the problem? If that would be the case, I would vote for it, provided the patch is technically sound (which I cannot judge).

My problem: I have deleted several feeds a while ago, but they keep getting retrieved (with errors because their URLs are no longer valid, but I still see the download messages in the bottom status bar). I have not deleted the old folder containing the historic feed entried because I want to keep it as an archive, but the feed subscriptions have been deleted long ago. Anyway, choosing "manage feeds" shows two phantom entries with the old feed URLs, but empty titles. I have tried to delete the entries, and after clicking "delete" they seem to be gone, but after a restart they are still there. The same applies to the feed URLs which are somehow still contained in the old feed folder's MSF file, like so:


<(80=1)(81=0)(82=4dd2520c)(83=26f32d)(86
    =https://consulting.projektwerk.com/profiles/latest.rss|http://it.projektw\
erk.com/profiles/latest.rss)(8D=1305629197)(CD=Fri Jul 01 10:58:00 2011)
  (89=12)(8A=2)(8B=)(8C
    ={"threadCol":{"visible":true},"attachmentCol":{"visible":true},"flaggedCo\
l":{"visible":true},"subjectCol":{"visible":true},"unreadButtonColHeader":{"vi\
sible":true},"senderCol":{"visible":true},"recipientCol":{"visible":false},"ju\
nkStatusCol":{"visible":true},"dateCol":{"visible":true},"locationCol":{"visib\
le":false}})>


Whatever this gibberish means, I recognise the residue of my supposedly deleted feeds.

Please tell me if this ticket is unrelated to my problem and whether there is an existing one which fits or I should create a new one.

Comment 5

[alta88]

this bug addresses some conditions which can cause the 'residue' you have to incorrectly remain.  but not all conditions.

to fix your problem, close Tb, delete the folder's .msf file (you will have to redo certain customizations like columns), and restart.  selecting the folder in question and doing a Get New Messages should rebuild the list (to empty) *if* the underlying feeds.rdf has the feeds for the folder (destFolder tag) removed.  the Subscribe dialog should then show just the folder and no feeds.

Comment 6

[alta88]

Attachment: fix3: get the feedUrl via getStringProperty rather than through msgDb getCharProperty

Comment 7

[[e-mail]]

Comment on attachment 577698 [details] [diff] [review]
fix3: get the feedUrl via getStringProperty rather than through msgDb getCharProperty

I don't really know the RSS code, so I can't comment on the deletion changes. Also this patch doesn't seem to eliminate all direct uses of msgDatabase.

Comment 8

[alta88]

Comment on attachment 577698 [details] [diff] [review]
fix3: get the feedUrl via getStringProperty rather than through msgDb getCharProperty


new patch coming.

Comment 9

[[e-mail]]

Just to show how little I know, I tried changing all the folder.msgDatabase.dBFolderInfo.getCharProperty into folder.getStringProperty and now my feed folders don't turn bold when they have new messages :-(

Comment 10

[alta88]

Attachment: fix.

Comment 11

[alta88]

try this patch (resubmit).

i had a more ambitious patch in mind, to get rid of even getStringProperty and thus really eliminate msgDatabase accesses, but it turns out the folder management design for feeds is really a piece of work.  folder renames/moves rely on the property, and do not sync the new folder with the underlying feeds db.  so the process very brittle and currently broken.  but this needs to be a follow up.

this patch merely catches some failures to allow a delete process to continue more fully and switches to getStringProperty.

Comment 12

[[e-mail]]

(In reply to comment #7)
> Also this patch doesn't seem to eliminate all direct uses of msgDatabase.
In fact it shouldn't, because it turns out you have to explicitly clear the database to persuade the folder to check for new messages...

Comment 13

[[e-mail]]

Comment on attachment 578271 [details] [diff] [review]
fix.

So, having unconfused myself, I thought I'd have another look at your patch in case I understood it.

>-      if ((currentTime - lastSeenTime) < INVALID_ITEM_PURGE_DELAY)
>+      if ((currentTime - lastSeenTime) < INVALID_ITEM_PURGE_DELAY && !aDeleteFeed)
>+        // Don't immediately purge items in active feeds; do so for deleted feeds.
I don't know what this does, so I can't comment.

>-    // Remove our feed url string from the list of feed urls
>-    var newFeedUrl = oldFeedUrl.replace(kFeedUrlDelimiter + aFeedUrl, "");
Eww. I'm glad you're getting rid of this.

>+    if (index != -1)
>+      curFeedUrls.splice(index, 1);
>+    else
>+      return;
Personally I'd prefer it if you'd write
if (index == -1)
  return;
curFeedUrls.splice(index, 1);
Similarly below for index != -1.

>-        folderInfo->GetCharProperty("feedUrl", url);
I don't understand why you didn't change this to use GetStringProperty.

Comment 14

[alta88]

(In reply to [e-mail] from comment #13)
> Comment on attachment 578271 [details] [diff] [review] [diff] [details] [review]
> fix.
> 
> So, having unconfused myself, I thought I'd have another look at your patch
> in case I understood it.
> 
> >-      if ((currentTime - lastSeenTime) < INVALID_ITEM_PURGE_DELAY)
> >+      if ((currentTime - lastSeenTime) < INVALID_ITEM_PURGE_DELAY && !aDeleteFeed)
> >+        // Don't immediately purge items in active feeds; do so for deleted feeds.
> I don't know what this does, so I can't comment.
> 

currently, if you unsubscribe a feed and delete the folder (note that deleting a folder without unsubscribing means you can't ever subscribe without manually cleaning feeds.rdf), then resubscribe, you won't get the current messages again, as they're in feeditems.rdf (dupe checking).  an active feed periodically purges these; deleting a feed has to purge them on deletion.

> >-    // Remove our feed url string from the list of feed urls
> >-    var newFeedUrl = oldFeedUrl.replace(kFeedUrlDelimiter + aFeedUrl, "");
> Eww. I'm glad you're getting rid of this.
> 
> >+    if (index != -1)
> >+      curFeedUrls.splice(index, 1);
> >+    else
> >+      return;
> Personally I'd prefer it if you'd write
> if (index == -1)
>   return;
> curFeedUrls.splice(index, 1);
> Similarly below for index != -1.
> 

of course.

> >-        folderInfo->GetCharProperty("feedUrl", url);
> I don't understand why you didn't change this to use GetStringProperty.

because the task of getting the urls is removed from GetNewMail and punted to downloadFeed in newsblog.js.

Comment 15

[alta88]

in writing a feed db cleaner i applied logging to my regular feeds, an old database which is a complete mess due to folder move/renames and multiple resubscribes etc etc going back to 3.1.

getStringProperty does not work the way we think it works.  

getCharProperty (after forcing msgDatabase to reparse if necessary) returns the feedUrl, but getStringProperty does not, in even a single instance.

i then applied this patch, and getStringProperty fails to get 1/3 of feedUrls.  is there a cache clearing needed before getStringProperty goes to the .msf?  because it's not working the same as getCharProperty.

Comment 16

[alta88]

Attachment: handle getStringProperty quirks

ensure we get the feedUrls by all (almost) means possible.  this patch uses setStringProperty if it doesn't have it, to store the feedUrl gotten by getCharProperty, so once done will never have to be accessed.  side benefit is the immediate open/population of the Subscribe dialog (used to be multisecond for not a huge number of feeds).

Comment 17

[alta88]

Attachment: add some code to clean up feedUrl string from past mishandling.

Comment 18

[[e-mail]]

Comment on attachment 578852 [details] [diff] [review]
add some code to clean up feedUrl string from past mishandling.

>-  rv = aFolder->GetMsgDatabase(getter_AddRefs(db));
This change seems to stop the folders from highlighting when they have new messages; I added it back and they started highlighting again. (I don't know whether your latest patch has the same problem.)

Comment 19

[[e-mail]]

Comment on attachment 578852 [details] [diff] [review]
add some code to clean up feedUrl string from past mishandling.

>+  var feedurls = aFolder.getStringProperty("feedUrl");
>+  if (feedurls) {
>+    feedUrlArray = feedurls.split(kFeedUrlDelimiter);
>+    return feedUrlArray.length ? feedUrlArray : null;
[split() never returns an empty array, except for "".split("")]

>+  // Go to msgDatabase for the property, make sure to handle errors.
>+  var msgDb;
>+  try {
>+    msgDb = aFolder.msgDatabase;
>+  }
>+  catch (ex) {}
>+  if (!msgDb || !msgDb.dBFolderInfo) {
>+    try {
>+      msgDb = aFolder.QueryInterface(Ci.nsIMsgLocalMailFolder)
>+                     .getDatabaseWOReparse();
[Actually I think GetMsgDatabase just calls GetDatabaseWOReparse]

>+      aFolder.msgDatabase = null;
[Not sure whether this is a good idea, see above]

Comment 20

[[e-mail]]

(In reply to comment #18)
> (From update of attachment 578852 [details] [diff] [review])
> >-  rv = aFolder->GetMsgDatabase(getter_AddRefs(db));
> This change seems to stop the folders from highlighting when they have new
> messages; I added it back and they started highlighting again. (I don't know
> whether your latest patch has the same problem.)
Indeed, the unread counts on my feeds don't update until I open the folder.

I also had a glitch where the first time I deleted a folder it wouldn't let me resubscribe to the feed. (After a restart it all worked properly.)

Neither with nor without the patch do I get more than one feed item if I delete and resubscribe to the feed.

Comment 21

[alta88]

(In reply to [e-mail] from comment #18)
> Comment on attachment 578852 [details] [diff] [review] [diff] [details] [review]
> add some code to clean up feedUrl string from past mishandling.
> 
> >-  rv = aFolder->GetMsgDatabase(getter_AddRefs(db));
> This change seems to stop the folders from highlighting when they have new
> messages; I added it back and they started highlighting again. (I don't know
> whether your latest patch has the same problem.)

odd.  the sole purpose of this in the cpp is to get/pass the property, and the same attempt has been simply moved to getFeedUrlsInFolder().

Comment 22

[alta88]

(In reply to [e-mail] from comment #19)
> Comment on attachment 578852 [details] [diff] [review] [diff] [details] [review]
> add some code to clean up feedUrl string from past mishandling.
> 
> >+  var feedurls = aFolder.getStringProperty("feedUrl");
> >+  if (feedurls) {
> >+    feedUrlArray = feedurls.split(kFeedUrlDelimiter);
> >+    return feedUrlArray.length ? feedUrlArray : null;
> [split() never returns an empty array, except for "".split("")]
> 

true, as getStringProperty returns either an empty string or not, and empty is already checked, this can simply be:

    return feedurls.split(kFeedUrlDelimiter);

> >+  // Go to msgDatabase for the property, make sure to handle errors.
> >+  var msgDb;
> >+  try {
> >+    msgDb = aFolder.msgDatabase;
> >+  }
> >+  catch (ex) {}
> >+  if (!msgDb || !msgDb.dBFolderInfo) {
> >+    try {
> >+      msgDb = aFolder.QueryInterface(Ci.nsIMsgLocalMailFolder)
> >+                     .getDatabaseWOReparse();
> [Actually I think GetMsgDatabase just calls GetDatabaseWOReparse]

it does, in cpp.  but there is no getMsgDatabase interface in either nsIMsgFolder or nsIMsgLocalMailFolder.  i think the mass change in bug 473458 may be a root cause.

-  var msgDatabase = msgFolder.getMsgDatabase(msgWindow);
+  var msgDatabase = msgFolder.msgDatabase;


> 
> >+      aFolder.msgDatabase = null;
> [Not sure whether this is a good idea, see above]

it shouldn't be needed unless the folder is user accessed, otherwise it's a lot of stuff hanging around for a lot of feeds that just wanted to update.  the switch to getStringProperty hopefully makes msgDb access unnecessary.  unless the premise is wrong.

Comment 23

[alta88]

(In reply to [e-mail] from comment #20)
> (In reply to comment #18)
> > (From update of attachment 578852 [details] [diff] [review] [diff] [details] [review])
> > >-  rv = aFolder->GetMsgDatabase(getter_AddRefs(db));
> > This change seems to stop the folders from highlighting when they have new
> > messages; I added it back and they started highlighting again. (I don't know
> > whether your latest patch has the same problem.)
> Indeed, the unread counts on my feeds don't update until I open the folder.
> 
> I also had a glitch where the first time I deleted a folder it wouldn't let
> me resubscribe to the feed. (After a restart it all worked properly.)
> 
> Neither with nor without the patch do I get more than one feed item if I
> delete and resubscribe to the feed.

the feed deletion process is quite interesting.  if you delete a feed folder in folder pane, it moves to trash.  you cannot resubscribe.  if you empty trash, the rdf:resource reference to the url is removed and you can resubscribe.  the feed entry however, is not removed so you get the same title/other attributes as before.  nor are any just downloaded current items in feeditems.rdf removed.  so once trash is emptied and you resub, you will get 1, and then only new items.  this patch does not address any of the folder pane delete/move/rename issues.

this patch does fix the removal of feeditems if removing a feed via the Subscribe dialog, which seems to do feed subscription delete/moves correctly as long as errors are caught, which is what this patch is trying to do.

Comment 24

[alta88]

(In reply to alta88 from comment #21)
> (In reply to [e-mail] from comment #18)
> > Comment on attachment 578852 [details] [diff] [review] [diff] [details] [review] [diff] [details] [review]
> > add some code to clean up feedUrl string from past mishandling.
> > 
> > >-  rv = aFolder->GetMsgDatabase(getter_AddRefs(db));
> > This change seems to stop the folders from highlighting when they have new
> > messages; I added it back and they started highlighting again. (I don't know
> > whether your latest patch has the same problem.)
> 
> odd.  the sole purpose of this in the cpp is to get/pass the property, and
> the same attempt has been simply moved to getFeedUrlsInFolder().

GetMsgDatabase opens the msgDb but also adds a listener and runs UpdateNewMessages() which sets new message flags etc, so it will need to stay.

Comment 25

[alta88]

Attachment: address comments

this addresses 1) array fixes, 2) opens msgDb in downloadFeed() for new msgs.  also ensure feedUrl changes processed on correct folder, not necessarily the destFolder in the feeds db, to prevent undeleteable ghost feeds in Subscribe dialog.

Comment 26

[David :Bienvenu]

Comment on attachment 578997 [details] [diff] [review]
address comments

in general, this looks OK. However, in a couple places, you say forcing a reparse with listener is the last resort, but I don't see any code that does that.  If that's correct, then the comment should probably reflect that.

I would also encourage you to use let instead of var in the js code where appropriate.

other than that, r=me, thx for the patch.

Comment 27

[alta88]

Attachment: address comments.

fixed let on most things i touched (never sure about policy with things that aren't central but need fixing and one just happens to be in the neighborhood).  feed code sure could use a general update, re let, Services, module, namespace, code style/commenting etc.

is sr+ required for checkin and if so who?

Comment 28

[Mark Banner (:standard8)]

sr isn't required (see https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements#Rules_for_all_patches_affecting_mailnews.2F_and_mail.2F)

Comment 29

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/a2cd7e37802f

Comment 30

[[e-mail]]

(In reply to alta88 from comment #22)
> (In reply to [e-mail] from comment #19)
> > (From update of attachment 578852 [details] [diff] [review])
> > >+  // Go to msgDatabase for the property, make sure to handle errors.
> > >+  var msgDb;
> > >+  try {
> > >+    msgDb = aFolder.msgDatabase;
> > >+  }
> > >+  catch (ex) {}
> > >+  if (!msgDb || !msgDb.dBFolderInfo) {
> > >+    try {
> > >+      msgDb = aFolder.QueryInterface(Ci.nsIMsgLocalMailFolder)
> > >+                     .getDatabaseWOReparse();
> > [Actually I think GetMsgDatabase just calls GetDatabaseWOReparse]
> it does, in cpp.  but there is no getMsgDatabase interface in either
> nsIMsgFolder or nsIMsgLocalMailFolder.
Sorry, I was unclear: GetMsgDatabase is the C++ name for the method that is called when you read .msgDatabase from script, which already calls GetDatabaseWOReparse for you. So this is still duplication of effort.

> i think the mass change in bug 473458 may be a root cause.
Well, it's the cause of the two things being equivalent ;-)

(In reply to alta88 from comment #23)
> this patch does fix the removal of feeditems if removing a feed via the
> Subscribe dialog, which seems to do feed subscription delete/moves correctly
> as long as errors are caught, which is what this patch is trying to do.
Ah, I didn't realise that this was how you are supposed to delete feeds.

Comment 31

[alta88]

(In reply to [e-mail] from comment #30)
> > i think the mass change in bug 473458 may be a root cause.
> Well, it's the cause of the two things being equivalent ;-)
> 

are they :)  iiuc, it went from a function to a getter.  and a throwing getter when merely asked..  so our various debugging tools showed it missing.

so this asks a much nicer function for a reply (but yes i noticed that if msgDatabase threw then nothing was gotten from getDBWORP either).

do you know what else throws?  getStringProperty under the right conditions.  this sort of thing make scripties unhappy.

> (In reply to alta88 from comment #23)
> > this patch does fix the removal of feeditems if removing a feed via the
> > Subscribe dialog, which seems to do feed subscription delete/moves correctly
> > as long as errors are caught, which is what this patch is trying to do.
> Ah, I didn't realise that this was how you are supposed to delete feeds.

no one would.  a patch is forthcoming to fix it, depends on Bug 709247.

Comment 32

[alta88]

didn't mean to change target, bugzilla doesn't cache well or something.

Comment 36

[Mark Banner (:standard8)]

Due to the issues mentioned in bug 711173, and the need for that fix to get more testing before release, we have taken the decision to back this out before the release. Therefore this will be included in Thunderbird 12, not 11 as previously expected.

Backout changeset:

http://hg.mozilla.org/releases/comm-beta/rev/e117463528ff

Comment 37

[drghughes]

I was hoping to test these changes as I have problems with some of my feed subscriptions, so I

- installed the Earlybird version,
- created a new profile,
- set up a "Blog & News Feed",
- closed Thunderbird,
- copied the feed files from my existing profile (Mail\News & Blogs) into the Mail\Feeds directory that Thunderbird had created in the new profile, and
- restarted Thunderbird.

However, while all the posts that had been downloaded in my normal profile are visible, when I check the subscriptions, there is nothing there.

Is there something else that I need to copy across from my existing profile to bring across all the existing subscriptions?

I don't want to copy the whole profile as that would mean I would have a second copy of all my email accounts.

Comment 38

[alta88]

that's not going to work.  first, if the account names are different, the folder urls in feeds.rdf won't match the folder urls in your new profile.

now, if you had copied the folder .msf files, it may have  worked (for some or all folders/feeds, depending on many things that caused feeds.rdf to be out of sync), since the .msf held (semi accurately) the feed urls for a folder.

however, copying a folder's .msf to another folder is bound to be a fail.

you would need to export and import into the new profile to do this correctly.  (since import/export is also problematic, you may not be able to recreate the old profile).

Comment 39

[drghughes]

Thanks for your explanation.

I'll copy the whole profile across and delete all the email accounts and test things that way.

Is there anything in particular that you'd like tested?

Comment 40

[alta88]

if you want the latest/greatest, install Tb13 for bug 716706.  there's a simple test script in bug 716706#c3.

primarily, the feeds.rdf db needs to be correctly synced to any folderpane moved/deletes, and the feed folders in Subscribe need to reflect the correct subscriptions.  just pound on it and note things that don't work as expected.  i'll tell you if they're known/unrelated/invalid..

Comment 41

[drghughes]

I'm not sure if this is the right place for these comments - please let me know if you'd like them elsewhere.

I just tried running v12.0a2 (2012-02-26) with an existing profile and when I checked the feeds that I've subscribed to:

- the subscription details are blank for the feed "account" that has nested folders; but
- the subscription details are correct for a second feed "account" that only has a single level of folders.

Before trying with v12.0a2 I'd tested the profile with v10.0.2 and I could see all the subscriptions in both feed "accounts".

I've also tried the profile with v10.0.2 after opening it with v12.0a2 and v10.0.2 was able to show all the subscriptions correctly, though it did seem to have to rebuild something as I got one of those messages about a script taking a long time to complete.

Comment 42

[alta88]

(In reply to drghughes from comment #41)
> I'm not sure if this is the right place for these comments - please let me
> know if you'd like them elsewhere.
> 

as good a place as any i guess.

> I just tried running v12.0a2 (2012-02-26) with an existing profile and when
> I checked the feeds that I've subscribed to:
> 
> - the subscription details are blank for the feed "account" that has nested
> folders; but
> - the subscription details are correct for a second feed "account" that only
> has a single level of folders.
> 

perhaps you could post a Tb10/Tb12 screenshots.  i can't reproduce it.  were there any errors in console?  you can also add a string Feeds.logging.console with value of 'debug' to the Config editor for console messages.

if you have more than 1 level, you've moved folders in folderpane, and feeds.rdf is definitely out of sync with what feed urls belong to what folders.  the sync in the v12 patches reads the feedUrls property in the folder's .msf and update feeds.rdf, then sets the property in panacea.dat (so .msf need not be referred to again). 

if you can try to find the url and folder name in .msf, feeds.rdf, and panacea.dat it would help to see what's where.  the mork files are not easy to figure out by visual inspection, but it can be done.

also, if you've manually hacked feeds.rdf or removed .msf files, things may be beyond repair.

> Before trying with v12.0a2 I'd tested the profile with v10.0.2 and I could
> see all the subscriptions in both feed "accounts".
> 
> I've also tried the profile with v10.0.2 after opening it with v12.0a2 and
> v10.0.2 was able to show all the subscriptions correctly, though it did seem
> to have to rebuild something as I got one of those messages about a script
> taking a long time to complete.

it would help to know what file this was in.  prior to this bug, Tb took a long time to build the Subscribe dialog tree.  going back is the wrong direction..

Comment 43

[drghughes]

Attachment: View of feed subscriptions in Thunderbird 10.0.2

A portion of the feed subscriptions in Thunderbird 10.0.2 showing examples of the nesting that I've used.

Comment 44

[drghughes]

Attachment: View of feed subscriptions in Earlybird 12.0a2

This should show the same results as the previous screenshot but is blank.

Comment 45

[drghughes]

Attachment: Unresponsive script message - feed-subscriptions.js

Comment 46

[drghughes]

(In reply to alta88 from comment #42)

Note that I updated to Earlybird 12.0a2 (2012-02-28) before the testing below, but the results were still the same.

> > I just tried running v12.0a2 (2012-02-26) with an existing profile and when
> > I checked the feeds that I've subscribed to:
> > 
> > - the subscription details are blank for the feed "account" that has nested
> > folders; but
> > - the subscription details are correct for a second feed "account" that only
> > has a single level of folders.
> > 
> 
> perhaps you could post a Tb10/Tb12 screenshots.  i can't reproduce it.

See above the attachments above.

> were there any errors in console?  you can also add a string
> Feeds.logging.console with value of 'debug' to the Config editor for console
> messages.

I added the Feeds.logging.console string.  When I clicked on the "Manage subscriptions" link in Earlybird 12.0a2 the following error appeared in the console:

Error: server is undefined
Source file: chrome://messenger-newsblog/content/utils.js
Line: 498

This was reproducible.

There was no error in Thunderbird 10.0.2.

> if you have more than 1 level, you've moved folders in folderpane, and
> feeds.rdf is definitely out of sync with what feed urls belong to what
> folders.

I don't really understand what you are saying here.  I've always added folders by right clicking in the normal Thunderbird window.  I don't believe that I've ever moved folders.

> the sync in the v12 patches reads the feedUrls property in the
> folder's .msf and update feeds.rdf, then sets the property in panacea.dat
> (so .msf need not be referred to again). 
> 
> if you can try to find the url and folder name in .msf, feeds.rdf, and
> panacea.dat it would help to see what's where.  the mork files are not easy
> to figure out by visual inspection, but it can be done.

As far as I can see the details in feeds.rdf are correct.  I've looked at one .msf file and it contains an awful lot of information.  The feed URL is repeated in what appears to be a record for each message in the feed.  panacea.dat appears to contain the folder structure but no URLs.

I don't know if it is relevant but I have been using the Thunderbird RSS reader for so long that the earliest feeds to which I subscribed have 8 character radmon alpha numeric folder/file names rather than the folder names that I have given them.
 
> also, if you've manually hacked feeds.rdf or removed .msf files, things may
> be beyond repair.

I haven't done this.

> > I've also tried the profile with v10.0.2 after opening it with v12.0a2 and
> > v10.0.2 was able to show all the subscriptions correctly, though it did seem
> > to have to rebuild something as I got one of those messages about a script
> > taking a long time to complete.
> 
> it would help to know what file this was in.  prior to this bug, Tb took a
> long time to build the Subscribe dialog tree.  going back is the wrong
> direction..

See the "Unresponsive script message attachment above.  Note that this is in Thunderbird 10.0.2, not Earlybird.

Comment 47

[alta88]

(In reply to drghughes from comment #46)
> 
> I added the Feeds.logging.console string.  When I clicked on the "Manage
> subscriptions" link in Earlybird 12.0a2 the following error appeared in the
> console:
> 
> Error: server is undefined
> Source file: chrome://messenger-newsblog/content/utils.js
> Line: 498
> 
> This was reproducible.
> 
> There was no error in Thunderbird 10.0.2.

thanks for the detailed diagnosis.  if you, in Tb12, right click on a folder (either account or any subfolder) and select Subscribe..., is the dialog tree also blank, or only if you invoke it from the account central screen and Manage Subscriptions?  and is it correct that the problem is for one particular feed account only?


> 
> See the "Unresponsive script message attachment above.  Note that this is in
> Thunderbird 10.0.2, not Earlybird.

the way it's done in Tb 10 is meant to be fixed in Tb 12, so this particular issue is fixed in this bug, not caused by it, or by downgrading from Tb 12.  i assume the script eventually completes and displays the tree.

Comment 48

[alta88]

(In reply to drghughes from comment #46)
> I added the Feeds.logging.console string.  When I clicked on the "Manage
> subscriptions" link in Earlybird 12.0a2 the following error appeared in the
> console:
> 
> Error: server is undefined
> Source file: chrome://messenger-newsblog/content/utils.js
> Line: 498
> 
> This was reproducible.
> 
> There was no error in Thunderbird 10.0.2.
> 

confirmed.  thanks for the outstanding help to track this down.  patch in Bug 732798.