@skyportradio@RL_Dane the render-vs-download is something I’ve been struggling with for years.
And when I built my extension I also understood what causes it - and why some feeds are displayed on the page and others trigger a download dialog.
It boils down again to content type. RSS and Atom in theory have their own mimetypes, but for some reason Firefox interprets e.g. application/rss+xml as a type that can’t be rendered in the browser - hence triggering the download dialog, even if it’s semantically the right mimetype to use.
But you know what’s a type that just gets rendered as-is in the browser? That’s right, text/xml! And that’s why many feed providers have resorted to using that as the content type of their feeds - even if it’s semantically incorrect, or approximative at the very least, even folks on StackOverflow advise to just use that. Mastodon uses the right mimetype instead, hence the issue.
That’s why my extension tries to render the feed in two ways:
If it’s a text/xml, then it parses the document on the rendered page, no problema.
If it’s an application/* that would otherwise trigger a download, it intercepts the response headers, renders the response body on the fly, and it cancels the download dialog before it can start.
Again, I’m a coder so I know how to get my way around these limitations, but this shouldn’t be how a standard is implemented. More clarifications from @mozilla on why they implemented such feed-hostile policies would be welcome.