RSS Viewer 的评价
RSS Viewer 作者： blacklight
blacklight 的回应
开发者回应
发布于 6 个月前Thanks for the feedback.
You seem to be impacted by two issues with RSS rendering in Firefox that I've tried to mitigate in this extension, but I can't guarantee to have eradicated completely.
1. File save dialog: that happens because the standard content types associated to feeds (application/rss+xml and application/atom+xml) aren't actually handled natively by Firefox (nor by Chromium AFAIK). So a file save dialog is triggered. The extension sniffs the response HTTP headers (`onHeadersReceived` callback in `background.ts`) to check if the content type matches one of those two known types and, if it does, interrupts the current request and swaps the cards under the table - it downloads the feed content in the background and renders it on the body. The card swap game may not always succeed though - race condition or browser configuration that limits the scope of what extensions can do with response headers. I've experienced the file save dialog myself a couple of times, but not very often.
2. Checking the body for RSS/Atom content: that's because of the other content type case - if it's not application/[rss|atom]+xml then it's often application/xml. Or even application/html, in some misconfigured cases. Either way, the raw XML gets rendered in the browser window. Hence the need to check if the document root is a known RSS/Atom root, and in such case do some JS magic to render the feed instead.
> When what I expect is it rendering the feed whichs url is being requested.
The only way for having this to work would be to check the current page for feeds published via , and only render those.
Unfortunately, not all websites publish their URL links like this. Many just put a link in their frontend. Many don't even publish their associated feeds. And the extension also needs to support the case where the user just enters a raw feed URL in the URL bar. Hence the need for doing things the way it does - sniffing content type headers, and swapping the cards in the body if the document is a feed. But this approach comes with trade-offs, which are mainly due to browser limitations.
I'm open to suggestions if anyone has better implementation ideas.
You seem to be impacted by two issues with RSS rendering in Firefox that I've tried to mitigate in this extension, but I can't guarantee to have eradicated completely.
1. File save dialog: that happens because the standard content types associated to feeds (application/rss+xml and application/atom+xml) aren't actually handled natively by Firefox (nor by Chromium AFAIK). So a file save dialog is triggered. The extension sniffs the response HTTP headers (`onHeadersReceived` callback in `background.ts`) to check if the content type matches one of those two known types and, if it does, interrupts the current request and swaps the cards under the table - it downloads the feed content in the background and renders it on the body. The card swap game may not always succeed though - race condition or browser configuration that limits the scope of what extensions can do with response headers. I've experienced the file save dialog myself a couple of times, but not very often.
2. Checking the body for RSS/Atom content: that's because of the other content type case - if it's not application/[rss|atom]+xml then it's often application/xml. Or even application/html, in some misconfigured cases. Either way, the raw XML gets rendered in the browser window. Hence the need to check if the document root is a known RSS/Atom root, and in such case do some JS magic to render the feed instead.
> When what I expect is it rendering the feed whichs url is being requested.
The only way for having this to work would be to check the current page for feeds published via , and only render those.
Unfortunately, not all websites publish their URL links like this. Many just put a link in their frontend. Many don't even publish their associated feeds. And the extension also needs to support the case where the user just enters a raw feed URL in the URL bar. Hence the need for doing things the way it does - sniffing content type headers, and swapping the cards in the body if the document is a feed. But this approach comes with trade-offs, which are mainly due to browser limitations.
I'm open to suggestions if anyone has better implementation ideas.