Closed Bug 364677 Opened 18 years ago Closed 15 years ago

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

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 3.6b1

People

(Reporter: philor, Assigned: philor)

References

Details

Attachments

(1 file)

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.
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
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".
According to the forum, setting correct Content-Type solved the problem. ->WORKSFORME
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
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.
Summary: No feed preview for this URL → No preview for sniffed feeds that don't have a channel/link or channel/id
(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).
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.
Attached patch Fix v.1 (deleted) — Splinter Review
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.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Attachment #384104 - Flags: review?(mano)
Whiteboard: [needs review mano]
Target Milestone: --- → Firefox 3.6a1
Comment on attachment 384104 [details] [diff] [review] Fix v.1 r=mano
Attachment #384104 - Flags: review?(mano) → review+
Whiteboard: [needs review mano] → [needs landing]
Target Milestone: Firefox 3.6a1 → Firefox 3.6b1
Status: ASSIGNED → RESOLVED
Closed: 18 years ago15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: