1049234 - Firefox is not displaying rss.xml files starting with v 31

Status: RESOLVED FIXED

(Firefox Graveyard :: RSS Discovery and Preview, defect)

Description

[marc]

Attachment: Screen Shot 2014-08-05 at 11.52.16 AM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

point Firefox v31 at any rss.xml file
for example, http://fm.kuac.org/feeds/term/1114/rss.xml


Actual results:

Firefox produces partial display of page - see attached screen capture


Expected results:

previous versions would display the feed items.

Comment 1

[:Gijs (he/him)]

This works for me - can you try restarting with add-ons disabled (Help > Restart with add-ons disabled) to check if it's being caused by one of your add-ons? If it isn't, can you open the browser console (cmd-shift-j), clear it, and then open the feed and see if you see any errors appear when the page is loading / loads?

Comment 2

[marc]

restart with add-ons disable produces same result.
log shows error

 Use of Mutation Events is deprecated. Use MutationObserver instead. menulist.xml:240
 readerURI is null FeedWriter.js:1346

Comment 3

[marc]

An example from another feed:

readerURI is null FeedWriter.js:1346
NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "readerURI is null" {file: "resource://app/components/FeedWriter.js" line: 1346}]'[JavaScript Error: "readerURI is null" {file: "resource://app/components/FeedWriter.js" line: 1346}]' when calling method: [nsIDOMGlobalPropertyInitializer::init] subscribe.js:13
TypeError: this._feedWriter is null

Comment 4

[:Gijs (he/him)]

I was contacted privately about this bug where this occurred under slightly different conditions. I think we should harden the feedwriter code to deal with error conditions such as the relevant webservice prefs being missing / invalid, and here with the URI being invalid (in which case we should probably skip the feed reader in the list of options). Setting needinfo so I don't forget to look at this this week.

Comment 5

[:Gijs (he/him)]

(In reply to marc from comment #3)
> An example from another feed:
> 
> readerURI is null FeedWriter.js:1346
> NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "readerURI is
> null" {file: "resource://app/components/FeedWriter.js" line:
> 1346}]'[JavaScript Error: "readerURI is null" {file:
> "resource://app/components/FeedWriter.js" line: 1346}]' when calling method:
> [nsIDOMGlobalPropertyInitializer::init] subscribe.js:13
> TypeError: this._feedWriter is null

Can you still reproduce this error, and if so, can you please do the following:

0. Open the feed that shows this error
1. Open the web developer tools (cmd-option-k)
2. Switch to the web developer settings (gear icon)
3. Toggle "Enable chrome and addon debugging"
4. open the browser console (cmd-shift-j)
5. Run the following:

var wccr = Cc["@mozilla.org/embeddor.implemented/web-content-handler-registrar;1"].
               getService(Ci.nsIWebContentConverterService);

for (let handler of wccr.getContentHandlers("application/vnd.mozilla.maybe.feed")) {
  console.log(handler.name, handler.uri);
}

for (let handler of wccr.getContentHandlers("application/vnd.mozilla.maybe.audio.feed")) {
  console.log(handler.name, handler.uri);
}

for (let handler of wccr.getContentHandlers("application/vnd.mozilla.maybe.video.feed")) {
  console.log(handler.name, handler.uri);
}

and copy/paste the output here? I'm trying to figure out how this got to be so broken. :-)

I'll attach a patch shortly that addresses the broken state, but it'd still be good to understand how this even happens.

Comment 6

[:Gijs (he/him)]

Attachment: deal with broken settings in feedwriter instead of dying completely,

Reproducing the pref being gone isn't difficult. Just set your feeds to always be done by My Yahoo (which we ship as a handler) and then in about:config remove the browser.feeds.handlers.webservice pref (reset). This is probably due to an add-on not cleaning up (I saw remnants of an add-on called microrss in the data that was emailed to me). We null-check all the other prefs, so it seems like we should be checking this one, too. The readerURI error from comment #3, I'm not sure how to reproduce - but if the uri is null, we should just not list it as an option, so I added a check for that. Trying to figure out how this is happening in comment #5, but I suspect the fix will be the same.

Comment 7

[:Gijs (he/him)]

Marco, can you add this?

Comment 8

[marc]

Output from console->

"My Yahoo!" "https://add.my.yahoo.com/rss?url=%s"
""

Comment 9

[marc]

Sorry for what is likely a silly question,  but doesn't use of https://add.my.yahoo.com/rss?url=%s require authentication in to Yahoo?

Comment 10

[:Gijs (he/him)]

(In reply to marc from comment #9)
> Sorry for what is likely a silly question,  but doesn't use of
> https://add.my.yahoo.com/rss?url=%s require authentication in to Yahoo?

Yes, but that's not the issue here. The issue is the extra line with an empty string.

If you run:

wccr.getContentHandlers("application/vnd.mozilla.maybe.feed").length

is that 2? (same question for the audio and video variants, ie replacing the bit in quotes with "application/vnd.mozilla.maybe.audio.feed" and "application/vnd.mozilla.maybe.video.feed")

Comment 11

[Marco Mucci [:MarcoM]]

Added to IT 34.3

Comment 12

[marc]

maybe produces 2, video produces 0, audio produces 0

Comment 13

[:Gijs (he/him)]

(In reply to marc from comment #12)
> maybe produces 2, video produces 0, audio produces 0

Right. And it's the second, empty, entry for 'maybe.feed' that is the issue here. Sadly, because the name is empty, I have no idea what was responsible for putting it there, but it sure is broken. :-\

Comment 14

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/integration/fx-team/rev/b48dd68342d7

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b48dd68342d7