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.