Closed
Bug 1120067
Opened 9 years ago
Closed 9 years ago
RSS (2.0?) feeds not updating and not being added.
Categories
(MailNews Core :: Feed Reader, defect)
Tracking
(thunderbird35 unaffected, thunderbird36 unaffected, thunderbird37 unaffected, thunderbird38 unaffected, thunderbird_esr38 unaffected, seamonkey2.32 fixed, seamonkey2.33 fixed, seamonkey2.34 fixed, seamonkey2.35 fixed)
RESOLVED
FIXED
Thunderbird 38.0
Tracking | Status | |
---|---|---|
thunderbird35 | --- | unaffected |
thunderbird36 | --- | unaffected |
thunderbird37 | --- | unaffected |
thunderbird38 | --- | unaffected |
thunderbird_esr38 | --- | unaffected |
seamonkey2.32 | --- | fixed |
seamonkey2.33 | --- | fixed |
seamonkey2.34 | --- | fixed |
seamonkey2.35 | --- | fixed |
People
(Reporter: Philipp, Assigned: ewong)
References
Details
Attachments
(1 file, 1 obsolete file)
1.47 KB,
patch
|
mkmelin
:
review+
Sylvestre
:
approval-comm-aurora+
Sylvestre
:
approval-comm-beta+
|
Details | Diff | Splinter Review |
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).
Comment 1•9 years ago
|
||
I can confirm this behavior, observed on x86_64 Linux beta builds of SeaMonkey 2.32...
Comment 2•9 years ago
|
||
(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
Assignee | ||
Comment 3•9 years ago
|
||
(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.
Reporter | ||
Comment 5•9 years ago
|
||
(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)
Reporter | ||
Updated•9 years ago
|
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.
Assignee | ||
Updated•9 years ago
|
status-seamonkey2.32:
--- → affected
status-seamonkey2.33:
--- → affected
Summary: SM2.32bx, RSS (2.0?) feeds not updating → SM2.32bx/SM2.33, RSS (2.0?) feeds not updating
Assignee | ||
Comment 8•9 years ago
|
||
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.
status-seamonkey2.34:
--- → affected
status-seamonkey2.35:
--- → affected
Summary: SM2.32bx/SM2.33, RSS (2.0?) feeds not updating → RSS (2.0?) feeds not updating and not being added.
Assignee | ||
Comment 9•9 years ago
|
||
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 | ||
Comment 10•9 years ago
|
||
(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.)
Comment 11•9 years ago
|
||
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)
Comment 12•9 years ago
|
||
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
Comment 13•9 years ago
|
||
(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.
Comment 14•9 years ago
|
||
The same problem upgrading from SM 2.31 to SM 2.32. Thank you in advance for your attention.
Comment 17•9 years ago
|
||
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 18•9 years ago
|
||
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)
Assignee | ||
Comment 19•9 years ago
|
||
(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?
Comment 20•9 years ago
|
||
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.)
Comment 22•9 years ago
|
||
"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
status-thunderbird35:
--- → affected
status-thunderbird36:
--- → affected
status-thunderbird37:
--- → affected
status-thunderbird38:
--- → affected
status-thunderbird_esr38:
--- → affected
Version: Trunk → 35
Assignee | ||
Comment 24•9 years ago
|
||
(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.
Comment 25•9 years ago
|
||
@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"?
Updated•9 years ago
|
tracking-thunderbird38:
--- → ?
Comment 26•9 years ago
|
||
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)
Comment 27•9 years ago
|
||
(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.
Assignee | ||
Comment 28•9 years ago
|
||
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/.
Assignee | ||
Comment 29•9 years ago
|
||
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)
Comment 30•9 years ago
|
||
(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 31•9 years ago
|
||
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+
Updated•9 years ago
|
Updated•9 years ago
|
Comment 32•9 years ago
|
||
https://hg.mozilla.org/comm-central/rev/195785150614 -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 38.0
Assignee | ||
Comment 33•9 years ago
|
||
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?
Assignee | ||
Comment 34•9 years ago
|
||
This will need to be pushed to c-a to c-r (especially c-r as it affects 2.32.)
Comment 35•9 years ago
|
||
(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 :)
Comment 36•9 years ago
|
||
Which release of SM is likely to get this fix?
Comment 37•9 years ago
|
||
(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)
Comment 38•9 years ago
|
||
a=me though I would have preferred an early return rather than pushing it into an if.
Comment 39•9 years ago
|
||
(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
Comment 40•9 years ago
|
||
OK, I'll keep a lookout for a 2.32.1 SM. Thanks guys.
Comment 41•9 years ago
|
||
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+
Comment 42•9 years ago
|
||
(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/
Comment 43•9 years ago
|
||
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.
Comment 44•9 years ago
|
||
(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.
Reporter | ||
Comment 45•9 years ago
|
||
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
Comment 46•9 years ago
|
||
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
Comment 47•9 years ago
|
||
It works in SeaMonkey 2.32.1 on OS X. Thank you all for your efforts and your team work.
Comment 48•9 years ago
|
||
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
Comment 49•9 years ago
|
||
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).
Assignee | ||
Comment 50•9 years ago
|
||
(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.
Assignee | ||
Comment 51•9 years ago
|
||
(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.
Comment 52•9 years ago
|
||
(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.
Assignee | ||
Comment 53•9 years ago
|
||
(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.
Comment 54•9 years ago
|
||
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.)
Assignee | ||
Comment 55•9 years ago
|
||
(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.
Assignee | ||
Updated•6 years ago
|
Attachment #8557735 -
Flags: approval-comm-release?
You need to log in
before you can comment on or make changes to this bug.
Description
•