Has anyone seen occurrences of the SharePoint 2010 RSS Viewer web part failing to complete loading when the page loads, instead remaining in constant "loading" mode with the Ajax indicator showing? I've seen it happen in several places now and haven't been able to identify what is causing it.

The RSS feed URLs aren't anything unusual, typically just BBC News or similar and definitely valid and working, it's just the web part which won't refresh.

I did ask about this on Twitter and got one reply suggesting it might be to do with sites where Alternate Access Mapping is set up but that doesn't seem conclusive for all instances I've seen.

Would be interested to hear if anyone else has seen this and if you ever resolved it

UPDATE 23 December: OK, can now see where/when the problem occurs. The problem pages are standard Team Site WIKI pages and have both the RSS Reader Web Part and the Status List (KPI) web part. As soon as I remove the Status List webpart the RSS Feed refreshes without problem. Add the Status List back and the RSS feed doesn't refresh. Again, would be interested to hear if others can reproduce this. I'm guessing that both of these webparts use AJAX and some form of UpdatePanel and there is a conflict.

  • We're having this exact same issue. Would love to hear from a MS mod on this one... Edit: Actually, I'm noticing a pattern where the RSS Reader will load properly if it's the only thing on the page that's being loaded. For example, use the Menu dropdown and select Edit Web Part. The reader loads right up, and if you make any changes and hit either Apply or OK it seems like SharePoint only reloads the one webpart, which leads to a proper load. What the hell?
    – user9806
    Aug 1, 2012 at 11:20
  • I have the exact same problem, two rss feeds and a custom web part with an update panel on it. I found that if I delay the load of the custom web part to wait for the rss feed to come, it works fine. However, this solution is not accepted for my project. We need to have both requests made after the page is fully loaded, and both request should come back without posting back the whole page. Please advise on how to proceed, Thanks in advance
    – L C
    Mar 14, 2013 at 14:18
  • I have the same issue. I added a SSRS Report Viewer web part to the same page as the RSS web part. At first it worked. Then I checked the "Asynchronous Rendering" box on the SSRS Report Viewer web part so the SSRS web part would not prevent the page from loading. As soon as I did this, I started experiencing the the clocking of the RSS web part. Mar 15, 2013 at 15:44
  • There doesnt seem to be any real consitancy besides load order with this. I myself am having a similar issue, I have two RSS feeds and 3 CQWP's on a page. The RSS feeds show when the page is checked out or checked in, but as soon as I publish the page they get stuck in loading.
    – Cory
    Apr 18, 2013 at 17:24

2 Answers 2


This topic is quite old but still valid since i just got the same behaviour from having 2 rss-feeds on a page and then adding a custom webpart with an updatepanel on it.

The rss-feeds hangs in loading state while the custom webpart loads just fine.

Havent been able to track down exactly what is causing it yet..

edit: Seems like it fixed "itself" now when i waited 500ms for the update of my custom webpart and then cache the content so i dont have to wait that 500ms every load ^^


I suggest you install Fiddler to see if there's any further detail happening via http that you aren't seeing (not sure if the webpart makes the request server-side or client-side). Fiddler should tell you either way. If the communication is client-side it will also tell you what response codes you're seeing from the target server.

If the http request to the rss feed is server-side, I suggest you checkout the ULS logs. There might be a security violation or some unexpected error that isn't surfaced to the webpart.

  • Hi Neil, See above, I've now narrowed it down to pages with both RSS Reader and Status List webpart...
    – user2055
    Dec 23, 2010 at 12:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.