RSS (2.0?) feeds not updating and not being added.

RESOLVED FIXED in Thunderbird 38.0

Status

defect
--
major
RESOLVED FIXED
5 years ago
10 months ago

People

(Reporter: Philipp, Assigned: ewong)

Tracking

Thunderbird 38.0
Dependency tree / graph

Thunderbird Tracking Flags

(thunderbird35 unaffected, thunderbird36 unaffected, thunderbird37 unaffected, thunderbird38 unaffected, thunderbird_esr38 unaffected, seamonkey2.32 fixed, seamonkey2.33 fixed, seamonkey2.34 fixed, seamonkey2.35 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31
Build ID: 20141125184518

Steps to reproduce:

Updating from SM2.31 to SM2.32beta2 or SM2.32beta3.

Using same profile, OS environment, etc. pp. as before.


Actual results:

(Some) RSS feeds don't update any more. Neither automatically, nor when calling "update all" / "update this" accounts.
As far as I can tell, it seems that "RSS" style feeds were affected, while "atom" style feeds are not. (Take this as a hint, not as a 100% fact.)
Same RSS-feed-URL does work for the live-bookmarks feature.
Same profile starts working again as soon as I revert back to SM2.31. (Fetched back from TimeMachine; now running in parallel on the system.)

Another user reported seeing on console:
2015-01-08 17:45:03	Feeds	WARN	subscribeToFeed: Aborting RSS
subscription. Feed downloads already in progress

See also threads on "News Reader SeaMonkey 2.32 beta 1 & 2" and "No RSS in 2.32bx" in mozilla.support.seamonkey


Expected results:

Feeds should update (whenever there are actual new items on the servers, of course).
I can confirm this behavior, observed on x86_64 Linux beta builds of SeaMonkey 2.32...
(In reply to Petr Voralek from comment #1)
> I can confirm this behavior, observed on x86_64 Linux beta builds of
> SeaMonkey 2.32...
Thanks for the confirmation
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Philipp van Hüllen from comment #0)
> User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0)
> Gecko/20100101 Firefox/34.0 SeaMonkey/2.31
> Build ID: 20141125184518
> 
> Steps to reproduce:
> 
> Updating from SM2.31 to SM2.32beta2 or SM2.32beta3.
> 
> Using same profile, OS environment, etc. pp. as before.
> 
> 
> Actual results:
> 
> (Some) RSS feeds don't update any more. Neither automatically, nor when
> calling "update all" / "update this" accounts.
> As far as I can tell, it seems that "RSS" style feeds were affected, while
> "atom" style feeds are not. (Take this as a hint, not as a 100% fact.)
> Same RSS-feed-URL does work for the live-bookmarks feature.
> Same profile starts working again as soon as I revert back to SM2.31.
> (Fetched back from TimeMachine; now running in parallel on the system.)
> 
> Another user reported seeing on console:
> 2015-01-08 17:45:03	Feeds	WARN	subscribeToFeed: Aborting RSS
> subscription. Feed downloads already in progress

I'm tracking this down, but I think it's something to do with
the RSS 2.0 feed handling (or rather, mishandling).

[Do note that I don't believe I've looked at the Feed code, so I'm doing this 
by trial and error. ;/ ]  But so far, atom and 1.0 rss feeds are ok.
2.0 are not.

Thanks for the report though.
OS: Mac OS X → All
Side note:  I'm using Aurora which appears to be working
properly with User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33a2

Don't know if this will help.
(In reply to gbukwa from comment #4)
> Side note:  I'm using Aurora which appears to be working
> properly with User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0)
> Gecko/20100101 Firefox/36.0 SeaMonkey/2.33a2

I tested this for my profile, and also on MacOS 10.10.1 SeaMonkey/2.33a2 works (again/still?).
As does SeaMonkey/2.31.

So either something that was broken in SeaMonkey/2.32b2/3 is fixed (again) in the Aurora, or some changes to SeaMonkey/2.32bX have not been applied to Aurora yet. (I don't know the branching/merging/lifting strategies in the project.)
This might help zoom in on the changes? (2.31 != 2.32 != 2.33)
Summary: SM2.32bx, RSS feeds not updating → SM2.32bx, RSS (2.0?) feeds not updating
I can confirm this bug.
SeaMonkey 2.31bX was working, while 2.32b1 and 2.32b2 was broken.
Did not checked 2.32b3, but final 2.32 neither works.
Duplicate of this bug: 1121719
Summary: SM2.32bx, RSS (2.0?) feeds not updating → SM2.32bx/SM2.33, RSS (2.0?) feeds not updating
I've tested from c-c to c-r and they're all affected.

User agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35a1

User agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 SeaMonkey/2.34a2

User agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33

User agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32

STR:

1) Open SeaMonkey
2) Goto http://www.seamonkey-project.org/news-atom
3) Click subscribe  [ it should open M&N and proceed to create Blogs & News 
   account and then download to SeaMonkey feed]
4) Goto http://news.google.com/news?pz=1&cf=all&ned=hk&hl=zh-TW&output=rss
5) Click on subscribe.  [ nothing happens in M&N ]
6) Open Error Console:
and you get this:

Feeds	WARN	subscribeToFeed: Aborting RSS subscription. Feed downloads already in progress

Any subsequent subscribe clicks to any other feed (Atom, etc) fails with
the same error.  

You need to delete the B&N account and then you can subscribe to any atom
or RSS1.0 feed.  Not RSS 2.0.

The binaries were built on a Win8.1Pro VS2013 system.
Summary: SM2.32bx/SM2.33, RSS (2.0?) feeds not updating → RSS (2.0?) feeds not updating and not being added.
Posted patch proposed patch (v1) (obsolete) — Splinter Review
sets a timeout before adding a feed to fix a race condition which
(from what I gather) the addFeeds() is being called before the
mSubscribeMode and the mNumPendingFeedDownloads are reset back.

I have tested this patch against c-c, and c-r.
Assignee: nobody → ewong
Status: NEW → ASSIGNED
Attachment #8550029 - Flags: review?(neil)
(In reply to Edmund Wong (:ewong) from comment #9)
> Created attachment 8550029 [details] [diff] [review]
> proposed patch (v1)
> 
> sets a timeout before adding a feed to fix a race condition which
> (from what I gather) the addFeeds() is being called before the
> mSubscribeMode and the mNumPendingFeedDownloads are reset back.
> 
> I have tested this patch against c-c, and c-r.

(oh, btw, the patch for c-r also requires the patch from bug
1069819.)
RSS 2.0 feeds not updating error seems to be related to bug 1069841.

And I can confirm that removing the "let" keyword from line 275 of chrome://messenger-newsblog/content/feed-parser.js and packing it in a custom XPI solves the problem for me. (SM2.32 on Win7 x64)
Is this bug also causing me, and others, from being unable to get to News groups on servers other than news.mozilla.com server??

Been unable to connect for past couple of days. I'm using the Beta version of SM ....

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32 Build identifier: 20150101220549
(In reply to Gabor Keresztfalvi from comment #11)
> RSS 2.0 feeds not updating error seems to be related to bug 1069841.
> 
> And I can confirm that removing the "let" keyword from line 275 of
> chrome://messenger-newsblog/content/feed-parser.js and packing it in a
> custom XPI solves the problem for me. (SM2.32 on Win7 x64)
With SeaMonkey 2.32 the relevant lines are:
http://mxr.mozilla.org/comm-central/source/mailnews/extensions/newsblog/content/feed-parser.js?rev=937875025e76&mark=274-275#274

> 274       // Support <category> and autotagging.
> 275       let tags = this.childrenByTagNameNS(itemNode, nsURI, "category");

Based on Bug 1069841 Comment 2 It is probable that this bug is a DUP of Bug 1069841
> From just reading the file, I think what happens here is that another |let
> tags| is defined on line 275, and since lets are hoisted to the top of their
> block in ES6, this is in the same scope as the use on line 133. The gotcha
> here is that even though the binding itself is hoisted (e.g., if I closed
> over 'tags' at line 133, I get the 'tags' binding declared on line 275), it
> can't be accessed until line 275 is executed.
The same problem upgrading from SM 2.31 to SM 2.32.
Thank you in advance for your attention.
Duplicate of this bug: 1123841
Duplicate of this bug: 1123552
Part of the fix for this landed in bug 1069819 (see comment 10), which will be in SM 2.33 but didn't make it into SM 2.32. It is basically what was mentioned in comment 11.
Comment on attachment 8550029 [details] [diff] [review]
proposed patch (v1)

Not sure why my review was requested here...
Attachment #8550029 - Flags: review?(neil) → review?(mkmelin+mozilla)
(In reply to neil@parkwaycc.co.uk from comment #18)
> Comment on attachment 8550029 [details] [diff] [review]
> proposed patch (v1)
> 
> Not sure why my review was requested here...

I was looking at https://wiki.mozilla.org/Modules/All#MailNews_Core and
came across Feeds which isn't owned.   It told me to ask Mailnews core peer.
It was between Mnyromyr, :kaie, you and :rkent.

Am I actually looking at the right module/subcomponent?
You're looking in the correct place. We should get that up to date though...

Anyway, I don't understand why the patch would help, can you explain?
(And random timeouts are usually not a correct fix anyway.)
Duplicate of this bug: 1125081
"Bug 1123190 - Unable to add a RSS feed" seems to be a DUP of this one.
Severity: normal → major
Component: MailNews: Backend → Feed Reader
Product: SeaMonkey → MailNews Core
Hardware: x86 → All
Version: SeaMonkey 2.32 Branch → Trunk
Duplicate of this bug: 1123190
(In reply to Magnus Melin from comment #20)
> You're looking in the correct place. We should get that up to date though...
> 
> Anyway, I don't understand why the patch would help, can you explain?
> (And random timeouts are usually not a correct fix anyway.)

I was putting a lot of dump() commands in between the code from feed-parser.js
to FeedUtils.jsm (and others).   (*only* dump() commands and + that 'let' fix
from bug 1069819.)

When I rebuilt SeaMonkey, it worked.  I was certainly confused.

So I removed the dump() commands (but left the 'let' fix) and rebuilt SeaMonkey;
but it failed.

I talked to RattyAway over on irc and  he said that I may have encountered a race
condition.  So after playing around with the code, I realized that RSS2 feeds
were the ones that were choking.  Once it got to the choked state, the variables 
(mSubscribeMode and mNumPendingFeedDownloads) were out of sync with the actual 
environment (already parsed items but not yet added), any subsequent tries of 
subscribing/updating RSS1 and atom feeds were broken.

As for how I got to that patch, I'll need to revisit the code and retrace
my steps. (Putting down a patch and then trying to remember how I got to
it, is no longer easy especially with code that I'm not familiar with. My
memory sucks, I know.)  I'll put up a short summary when I get the chance.
@Edmund Wong: Are your oservations also concerning "Some existing Feeds do not update contents" problem (here in Summary and also observed in Bug 1123190) or only concerning "No Feeds can be added"?
Comment on attachment 8550029 [details] [diff] [review]
proposed patch (v1)

Review of attachment 8550029 [details] [diff] [review]:
-----------------------------------------------------------------

Please re-request review once you've figured out why it helps. Or likely, what the real fix is.
Attachment #8550029 - Flags: review?(mkmelin+mozilla)
(In reply to Edmund Wong (:ewong) from comment #9)
> proposed patch (v1)

This patch does not solve the Not Updating issue. 

Please add this major issue to the Known Issues section in http://www.seamonkey-project.org/releases/seamonkey2.32  I downgraded to 2.31 because of this.
From further tracing (and looking at the error log), 
http://hg.mozilla.org/comm-central/annotate/f0194350ebf3/mailnews/extensions/newsblog/content/FeedUtils.jsm#l595

is problematic in SeaMonkey because win.gFolderTreeView doesn't exist and
so setFolderPaneProperty() chokes.

Looking at the code, gFolderTreeView() is defined in mail/ but not in
suite/.
Avoid the rest of the setFolderPaneProperty() when Services.wm.getMostRecentWindow("mail:3pane") doesn't have the gFolderTreeView
property.
Attachment #8550029 - Attachment is obsolete: true
Attachment #8557735 - Flags: review?(mkmelin+mozilla)
(In reply to Matilda from comment #14)
> The same problem upgrading from SM 2.31 to SM 2.32.
> Thank you in advance for your attention.

I have the same problem. First I thought the sides didn't actualised their feeds but it was more sites. Some minutes ago, I changed back to SM 2.31 and I get new posts in different RSS-feeds again.

I have Windows 7 32-bit if somebody needs this information.

SM 2.32 always shows in status-bar that it searches for new content but I can wait as long as I want but nothing comes. And after some tries (in different feeds), the program doesn't responds in the status-bar when I press [CTRL+D] for manual actualizing.
Comment on attachment 8557735 [details] [diff] [review]
proposed patch (v2)

Review of attachment 8557735 [details] [diff] [review]:
-----------------------------------------------------------------

Ah yes this looks better, r=mkmelin
Attachment #8557735 - Flags: review?(mkmelin+mozilla) → review+
https://hg.mozilla.org/comm-central/rev/195785150614 -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 38.0
Comment on attachment 8557735 [details] [diff] [review]
proposed patch (v2)

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: RSS not being added
Testing completed (on c-c, etc.): 
Risk to taking this patch (and alternatives if risky): none
Attachment #8557735 - Flags: approval-comm-release?
Attachment #8557735 - Flags: approval-comm-beta?
Attachment #8557735 - Flags: approval-comm-aurora?
This will need to be pushed to c-a to c-r (especially c-r as it affects
2.32.)
(In reply to Edmund Wong (:ewong) from comment #33)
> [Approval Request Comment]
> Regression caused by (bug #): 
> User impact if declined: RSS not being added
> Testing completed (on c-c, etc.): 
> Risk to taking this patch (and alternatives if risky): none

A few information are missing here. Could you detail the tests that you have done?
(and I don't agree with "none" as risk. All changes have risks... but this is a different story :)
Which release of SM is likely to get this fix?
(In reply to Sylvestre Ledru [:sylvestre] from comment #35)

> A few information are missing here. Could you detail the tests that you have
> done? (and I don't agree with "none" as risk. All changes have risks... but
> this is a different story :)

Regression caused by (bug #): Bug 993371 
User impact if declined: RSS2 feeds cannot be added or updated.
Testing completed (on c-c, etc.): 
Risk to taking this patch (and alternatives if risky): this change does not change the program flow for Thunderbird so no risk there. OTOH this is a correctness fix for SeaMonkey.
Flags: needinfo?(sledru)
a=me though I would have preferred an early return rather than pushing it into an if.
(In reply to Ian Neal from comment #38)
> a=me though I would have preferred an early return rather than pushing it into an if.
Pushed to comm-release SeaMonkey only:
http://hg.mozilla.org/releases/comm-release/rev/3486444fb645
OK, I'll keep a lookout for a 2.32.1 SM.  Thanks guys.
Comment on attachment 8557735 [details] [diff] [review]
proposed patch (v2)

Approving for now on aurora & beta. Let's wait a few days before approving for release.
Flags: needinfo?(sledru)
Attachment #8557735 - Flags: approval-comm-beta?
Attachment #8557735 - Flags: approval-comm-beta+
Attachment #8557735 - Flags: approval-comm-aurora?
Attachment #8557735 - Flags: approval-comm-aurora+
(In reply to Ian Goddard from comment #40)
> OK, I'll keep a lookout for a 2.32.1 SM. 

At least for Windows the Release Candidates have this error fixed. Downloads are available at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2.32.1-candidates/build1/
Result of a first quick test with User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1
Build-Identifikator: 20150204202218 on WIN7 is promising, I can register new feeds, and they do update.
(In reply to :Hb from comment #42)
> (In reply to Ian Goddard from comment #40)
> > OK, I'll keep a lookout for a 2.32.1 SM. 
> 
> At least for Windows the Release Candidates have this error fixed. Downloads
> are available at
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2.32.1-candidates/
> build1/

Downloaded linux-686 en_GB version.  Downloaded OK.  I'll keep using this version & report back if there seem to be any problems, otherwise no news is good news.  Or in this case some newsfeeds are good news ;) Once again, thanks Edmund & others.
Nice job. Confirmed for Mac:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1
Build-Identifikator: 20150204214408
2.32.1 WORKS4ME for Win7/32:

User agent: Mozilla/5.0 (Windows NT 6.1; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1
Build identifier: 20150204202218

Fine, fast work, everyone!  -JW
It works in SeaMonkey 2.32.1 on OS X. Thank you all for your efforts and your team work.
Bug 1137072 happened because I forgot to push to comm-beta and comm-aurora. So now I have to push to -release and -beta
Pushed to comm-release:
http://hg.mozilla.org/releases/comm-release/rev/b1a671eb4b4b
Pushed to comm-beta:
http://hg.mozilla.org/releases/comm-beta/rev/3524c4cb9d10

status-seamonkey2.34 => really fixed
status-seamonkey2.35 => really fixed
Depends on: 1137072
I saw this patch when I did the aurora and beta pushes for Thunderbird, but because it was SeaMonkey only I did not push it. The perma-closed nature of the SeaMonkey repo does not help any here. I sort of assume that means that you do not want people pushing to the SeaMonkey repos unless they are on the SeaMonkey team (though I will push SM changes that are needed because something changes in mailnews that would break S-M if not pushed).
(In reply to Kent James (:rkent) from comment #49)
> I saw this patch when I did the aurora and beta pushes for Thunderbird, but
> because it was SeaMonkey only I did not push it. The perma-closed nature of
> the SeaMonkey repo does not help any here. I sort of assume that means that
> you do not want people pushing to the SeaMonkey repos unless they are on the
> SeaMonkey team (though I will push SM changes that are needed because
> something changes in mailnews that would break S-M if not pushed).

Sorry.. that's not the case.  Patches and pushes are welcomed by anyone,
just as long as the patches are reviewed. :)

The reason we're perma closed is because of our infra. Win32 is permanently
red until we get the new windows slaves.
(In reply to Philip Chee from comment #48)
> Bug 1137072 happened because I forgot to push to comm-beta and comm-aurora.
> So now I have to push to -release and -beta
> Pushed to comm-release:
> http://hg.mozilla.org/releases/comm-release/rev/b1a671eb4b4b
> Pushed to comm-beta:
> http://hg.mozilla.org/releases/comm-beta/rev/3524c4cb9d10
> 
> status-seamonkey2.34 => really fixed
> status-seamonkey2.35 => really fixed

Sorry Philip.  I missed these pushes.  My bad.  Thanks for the pushes.
(In reply to Edmund Wong (:ewong) from comment #50)
> 
> The reason we're perma closed is because of our infra. Win32 is permanently
> red until we get the new windows slaves.

So I'm still confused. Do you want patches pushed, or not? If yes, then why do you keep the repo perma-closed? That's what closed means, please do not push patches.
(In reply to Kent James (:rkent) from comment #52)
> (In reply to Edmund Wong (:ewong) from comment #50)
> > 
> > The reason we're perma closed is because of our infra. Win32 is permanently
> > red until we get the new windows slaves.
> 
> So I'm still confused. Do you want patches pushed, or not? If yes, then why
> do you keep the repo perma-closed? That's what closed means, please do not
> push patches.

Sorry for the confusion.  The tree should be considered APPROVAL-ONLY, tbh.
Then could you please set it to that and not closed? It's highly annoying to have to put "CLOSED TREE" into every patch you push that touches seamonkey mailnews strings. (And I wouldn't consider those requiring much approval - with a seamonkey closed tree since almost a year, I don't think it's good value of anybody's time to hunt down explicit approval for landing them.)
(In reply to Magnus Melin from comment #54)
> Then could you please set it to that and not closed? It's highly annoying to
> have to put "CLOSED TREE" into every patch you push that touches seamonkey
> mailnews strings. (And I wouldn't consider those requiring much approval -
> with a seamonkey closed tree since almost a year, I don't think it's good
> value of anybody's time to hunt down explicit approval for landing them.)

The trees will be marked approval required as soon as we resolve our 
current linux infra issue.  Sorry for the inconvenience.
Duplicate of this bug: 1137072
Attachment #8557735 - Flags: approval-comm-release?
You need to log in before you can comment on or make changes to this bug.