Recensioni per RSS Viewer
RSS Viewer di blacklight
Recensione di Jan Klass
Valutata 1 su 5
di Jan Klass, 7 mesi faDoesn't work correctly.
May or may not show the feed view.
Always opens a file save dialog anyway.
When I open the feed in a new tab, it closes my new tab, and navigates the previous tab.
Looking at the code, I got confused about it seemingly looking for RSS feeds within a page and rendering them. When what I expect is it rendering the feed whichs url is being requested.
May or may not show the feed view.
Always opens a file save dialog anyway.
When I open the feed in a new tab, it closes my new tab, and navigates the previous tab.
Looking at the code, I got confused about it seemingly looking for RSS feeds within a page and rendering them. When what I expect is it rendering the feed whichs url is being requested.
Replica dello sviluppatore
pubblicato il 7 mesi faThanks 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.
2 recensioni
- Valutata 5 su 5di Utente Firefox 18221896, un anno fa