743467 - Fetching new posts for feed account broken

Status: RESOLVED FIXED

(MailNews Core :: Feed Reader, defect)

Description

[Merike Sell (:merike)]

Something within http://hg.mozilla.org/releases/comm-aurora/pushloghtml?fromchange=6b8a03850000&tochange=a97e6cafdc03 (probably bug 711173) broke F5 on feed accounts for me. I can still update by selecting single destination folder and pressing F5 which is tedious for the number of folders I have. Shift+F5 only updates email and news accounts. http://hg.mozilla.org/releases/comm-aurora/rev/788690fde22b is also broken, haven't tried newer ones.

Caught this in error console:
uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgFolder.getStringProperty]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://messenger-newsblog/content/utils.js :: getFeedUrlsInFolder :: line 345"  data: no]
I do have folders without feeds (have removed some subscriptions in the past but not destination folders) and also folders with multiple feeds.

Comment 1

[alta88]

this is due to an .msf file that needs to be rebuilt.  likely just selecting the folder (account) should cause that to happen and F5 should work.  bug 738726 fixes the need to do even that.  shift-F5 gets all accounts (feeds included) for me in Tb.

perhaps you can try with the latest trunk, before selecting the folder, and report back.

Comment 2

[Merike Sell (:merike)]

I tried 20120407030055 comm-central build. Since it didn't seem to work better I tried deleting .msf files for two accounts. Sadly, that doesn't seem to make any difference either. I also noticed that when I open subscribing dialog for a single folder I can't see the feeds for it, yet fetching posts works fine as long as I do it folder by folder.

What else can I try? There doesn't seem to be any related messages in error console.

Comment 3

[alta88]

the patch is in the 0408 build.  if you select the account folder, that would rebuild (i believe it works for accounts the same as an other folder).  then rt click, Get Messages should get them all.

you can add the following pref: Feeds.logging.console, set to debug.

Comment 4

[alta88]

well, it turns out if the account .msf can't be opened (sometimes a timestamp mismatch) or is missing, it is not rebuilt on selection, like subfolders.  not good.  however, the patch fixes that.  it will have to be requested for beta/aurora for cases such as yours.

Comment 5

[alta88]

merike, can you confirm build of at least 0408 fixes this?

Comment 6

[Merike Sell (:merike)]

Tried 0410 build and saw no difference. To me it doesn't seem like an issue of broken .msf files. After trying out this build I also tried deleting all of feed-related .msf files. This had the result of making

[Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgFolder.getStringProperty]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://messenger/content/folderPane.js :: getSmartFolderName :: line 2476"  data: no]

disappear entirely from error console but didn't make feed accounts work properly as with 0221 build. Subscription dialog still shows nothing for folders that work when updated separately but logs the same error as in bug description.

Comment 7

[alta88]

are you trying with trunk (Tb14) builds?  is the logging pref set?  if so, what appears in the console immediately after you F5 on a selected feed account.

if you'd rather not use a trunk build on a real profile, perhaps you could create a new profile with trunk, create a Newsblog account, and copy everything from the old Mail/[Newsblog name] folder to the new profile.

if you delete a folder's .msf, various other code in Tb will throw the NS_ERROR.  for example if you merely mouse over it.  selecting the folder rebuilds it.

Comment 8

[alta88]

Attachment: patch.

[Approval Request Comment]
Regression caused by (bug #): 
-  bug 705504 introduced getting the folder feedUrl property using getStringProperty.
User impact if declined: 
- in some cases, Get Messages, biffs, F5 on the account folder will fail.
Testing completed (on m-c, etc.):
- local testing.
Risk to taking this patch (and alternatives if risky):
- almost zero.
String changes made by this patch:
- none.

the patch in bug 738726 doesn't quite cover it for all cases the account folder is accessed; this should do it.

Comment 9

[Alex Keybl [:akeybl]]

Comment on attachment 614008 [details] [diff] [review]
patch.

It's not clear if this needs mozilla or comm approval - regardless, this patch hasn't even been r+'d or landed on the dev branch. Please re-nominate with appropriate approval once that's occurred.

Comment 10

[alta88]

(In reply to Alex Keybl [:akeybl] from comment #9)
> Comment on attachment 614008 [details] [diff] [review]
> patch.
> 
> It's not clear if this needs mozilla or comm approval - regardless, this
> patch hasn't even been r+'d or landed on the dev branch. Please re-nominate
> with appropriate approval once that's occurred.

sorry, wrong boxes ticked..

Comment 11

[Ryan VanderMeulen [:RyanVM]]

"Never any feedUrls in the account folder or trash folder" ??? I added a "get" in there since I think that's what you meant.
http://hg.mozilla.org/comm-central/rev/f900fbf5e406

Also, is it possible to test this?

Finally, this patch was missing user information and a commit message. Please follow the directions shown below on future patches.
https://developer.mozilla.org/en/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F

Comment 12

[Merike Sell (:merike)]

(In reply to alta88 from comment #8)
> Created attachment 614008 [details] [diff] [review]
> patch.
Thanks so much, this fixed it for me!

Comment 13

[Justin Wood (:Callek)]

[beta] http://hg.mozilla.org/releases/comm-beta/rev/4002af09bc21

Comment 14

[Mark Banner (:standard8)]

This was checked in on aurora here:

http://hg.mozilla.org/releases/comm-aurora/rev/a5d3845c3910

Comment 15

[alta88]

(In reply to Merike (:merike) from comment #12)
> (In reply to alta88 from comment #8)
> > Created attachment 614008 [details] [diff] [review]
> > patch.
> Thanks so much, this fixed it for me!

Merike, it would be somewhat interesting to see, now that this tweak has allowed the auto repair to function on account folders, if you have the issue running the profile under Tb12 beta..

Comment 16

[Merike Sell (:merike)]

Um, where would I get a beta more recent than ftp://ftp.mozilla.org/pub/thunderbird/releases/12.0b4/ ? This seems to be earlier than matching check-in.

Comment 17

[alta88]

no, it should work in any old beta now that it's been (supposedly) autorepaired..

Comment 18

[Merike Sell (:merike)]

Ran the same profile with Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120410 Thunderbird/12.0. F5 on account did not work.

Comment 19

[Mark Banner (:standard8)]

(In reply to alta88 from comment #17)
> no, it should work in any old beta now that it's been (supposedly)
> autorepaired..

You'll need b5 which will be out later this week, as the patch has only just landed on the beta channel.

Comment 20

[alta88]

the theory is, if the tweak in this patch allowed the auto reparse repair in bug 738726 to proceed, then merely running Tb14 with both patches would fix the getStringProperty throw.  if it were indeed a .msf file needing a reparse.

therefore, the profile with the reparsed account folder .msf should have worked in Tb12.  since it didn't, this tweak is merely bypassing some other issue with the feed account folder and getStringProperty.  which is fine for feeds since there are no feed urls attached to an account.

since account folder pretty names are stored in prefs, unlike subfolders, i think getStringProperty hasn't been exercised much on account folders..