364677 - No preview for sniffed feeds that don't have a channel/link or channel/id

Status: RESOLVED FIXED

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

Description

[Phil Ringnalda (:philor)]

Nothing jumps out at me as an obvious reason why we would be failing to parse it, but http://mediatheque.cite-musique.fr/RSS/RSSConcerts.xml displays with its stylesheet, rather than as a preview, and http://mediatheque.cite-musique.fr/RSS/RSSConcertsLight.xml (the no-stylesheet version) just gets XML prettyprinting. Regression on trunk in a big gap where I don't have builds, between 2006-11-09 ~21:30 and 2006-11-23 ~15:30, also fails to show preview in 2.0.0.1.

Comment 1

[François Guillot]

After reading all the talk about the "Firefox overriding XSLT stylesheets in RSS feed" I taught a decision had been taken to no longer override it. Now I know it's not the case, I know also there is really a problem.

Maybe it occurs because our website is made of framesets.

I'm part of the team behind the site so if anyone has questions about it, do not hesistate...
fguillot[at]cite-musique.fr (this is a french multimedia library)

One important precision : this problem happened when Firefox upgrades to version 2.0.0.1. The feed view is perfectly displayed with version 2.0.0.0.

More details here :
http://forums.mozillazine.org/viewtopic.php?p=2663470#2663470

Comment 2

[François Guillot]

This is a WONTFIX.

It was a problem of MIME type. Firefox 2.0 could handle with "text/xml" but Firefox 2.0.0.1 needs "application/rss+xml".

Comment 3

[O. Atsushi (Torisugari)]

According to the forum, setting correct Content-Type solved the problem.

->WORKSFORME

Comment 4

[Phil Ringnalda (:philor)]

Um, no, and no. This would be a wontfix if we intentionally dropped all the very expensive code we have to sniff all sorts of mime-types, instead deciding to require use of an unregistered mime-type, and did that between 2.0 and 2.0.0.1, but we didn't, and wouldn't. This would be worksforme if the bug was really about "this URL" rather than about "a URL with whatever unknown characteristic of this URL that causes this behavior."

Feel free to resolve it if you can say which of the six RSS D&P bugs that are fixed1.8.1.1 or verified1.8.1.1 caused the change in behavior, and why it was an intended effect rather than an unintended side-effect of that bug; otherwise, hands off.

Comment 5

[Phil Ringnalda (:philor)]

Ah, bug 361230 required sniffed content to have either a link or an id at the channel level, which François' feed lacks. Interesting that feedvalidator.org doesn't mind not seeing a channel/link in RSS, since every single spec back to 0.90 has required it.

Comment 6

[O. Atsushi (Torisugari)]

(In reply to comment #5)
> Ah, bug 361230 required sniffed content to have either a link or an id at the
> channel level, which François' feed lacks. Interesting that feedvalidator.org
> doesn't mind not seeing a channel/link in RSS, since every single spec back to
> 0.90 has required it.
> 

You are right. I missed that line (result.doc.id || result.doc.link).

Comment 7

[François Guillot]

OK I get it. My boss asked me to remove the <link> in <channel> because it was creating a "mirror effect" with the framesets of our website. By clicking on the title of the feed or the image when displayed in our frameset, the website was opening again in the frameset, and again and again for each click, resulting in a website in a website in a website, etc...

We removed the MIME type, but the <link> back (and according to feedvalidator I also put a <link> for the image and a <guid> for each <item>) and it works.

I didn't get all the WONTFIX / WORKSFORME stuff but I think we're done.

Comment 10

[Phil Ringnalda (:philor)]

Attachment: Fix v.1

Remarkably enough, bug 394416's removal of sniffing text/plain, which was the reason we needed the hack of pretending that no channel/link meant a feed was a template rather than a feed, has managed to stick clear from b1 to rc1, so I guess we can go ahead and revert this.

The test is pretty much a clone of test_bug395533.html, which ran fine until the change to not sniffing text/plain made it check in the other direction, so I expect it not to be too noisy.

The only other thing I really changed was hoisting up the comment about "no automatic handler" - it took me a lot of studying CVS history to figure out that it wasn't talking about some removed code that used to be inside that if block, but was instead explaining how we managed to get out of the try block above.

Comment 11

[Asaf Romano (gone)]

Comment on attachment 384104 [details] [diff] [review]
Fix v.1

r=mano

Comment 12

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/mozilla-central/rev/1a8c4b33e9da