637155 - Allow subscribing to feeds with malformed XML, and show whatever items can be parsed up to the parsing error

Status: RESOLVED WONTFIX

(MailNews Core :: Feed Reader, enhancement)

Description

[Martin Kudlej]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110221 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

It is not possible to subscribe rss:
https://is.cuni.cz/studium/nastenka/rss.php?string_kod=&string_nazev=&string_prijmeni=&string_fak=11230&string_gl=&string_datum=1.1.1000&string_kat=

but it is possible to subscribe to RSS with similar link on same server:
https://is.cuni.cz/studium/nastenka/rss.php?string_kod=&string_nazev=&string_prijmeni=&string_fak=&string_gl=&string_datum=1.1.1000&string_kat=

In Firefox(4.x) work both examples.

Reproducible: Always

Steps to Reproduce:
1. try to add RSS https://is.cuni.cz/studium/nastenka/rss.php?string_kod=&string_nazev=&string_prijmeni=&string_fak=11230&string_gl=&string_datum=1.1.1000&string_kat=

Actual Results:  
It is not possible to add above RSS.

Expected Results:  
It will be possible to add above RSS and Thunderbird will properly show content of that RSS.

Comment 1

[Phil Ringnalda (:philor)]

Even though we've probably marked dozens of similar bugs as invalid, really this is a valid enhancement request (that I'll be surprised if anyone works on).

Firefox's feed preview made the decision, valid under XML's rules, to parse up until an XML parsing error and show the results (and then has been waiting for literally years for some UX input on how to tell people that there was an XML parsing error, which is why it looks like it has no problem with the feed - it wants to display a big red flashing "XML Parsing Error Here!!1!" message at the bottom, but nobody has told it what it should say). Since that particular feed's XML parsing error is "junk after document element" and the fact that it has "soubor nelze otevrit" after the "</rss>" doesn't leave anything visibly missing, it looks like it "works."

Thunderbird and Firefox's Live Bookmarks made the decision, equally valid under XML's rules, to display nothing from a feed when there was a parsing error.

"All" someone has to do to fix this is to think their way through both subscription and feed parsing, figuring out what we need from the feed and how we'll survive if it's missing - "what will we do, while subscribing, if we are able to parse the items, but we can't parse the feed title because someone put the items before the channel metadata, and put a parser error in the metadata?," "what will we do with an item where we parse only the (link, title, date, description) but nothing else?"

... while keeping in mind that any message we use may be confused with the actual feed data, since I subscribe to a feed with the title "404 Not Found."

Oh, and since I'm pretty sure that at least the parser we're currently using for RSS 1.0 doesn't actually give us any data at all when it hits a parsing error, the hypothetical someone would first need to switch us to using the toolkit feed parser.

Comment 3

[alta88]

Commnet 1 is well stated and correct, but it's time to close this.  The feed above also happens to work.  The policy reasons are:

1. The primary real life xml validation failure is publishers using octal or other illegal representations of utf8 chars/symbols. As the world has moved into utf8 everywhere, this has greatly diminished.  Bad tags/mismatches are likely a much rarer cause.
2. The specs are well known; the validator is well known.
3. To fix this would require not relying on the gecko validated xml object but changing the xhr request to get the whole document and parse it if gecko fails it on xml.  This is a gross inefficiency for everyone else, for an edge case due to publisher failure re #2 above.
4. Using the toolkit feed parser would be a grave strategic mistake for Tb at this point.
5. No one's going to work on this nor should anyone.