After careful consideration of various options (which also included doing nothing, or investing heavily in updating the code), we've decided to go ahead and remove builtin feed support from Firefox. This metabug covers both the removal and creating public documentation for users (e.g. on support.mozilla.org ) of alternatives.

Foxish bookmarks for Chrome is an add-on which does more or less the same thing: https://github.com/davidhampgonsalves/foxish It will need some work to make it compatible with Firefox. I have made a start here: https://github.com/ali1234/foxish The core functionality works - you can subscribe to a feed using the options page and the bookmarks will be created. The rest does not work due to apparently unimplemented functions in Firefox extensions API.

I'm expecting to be marked as "advocating" but I hope you realize this move might prompt more website administrators to stop offering RSS feeds at all. Life is getting harder as it goes for an RSS user like me, and this puts another nail in the coffin. And no, Pocket does not do what I want - I use RSS to gather all my news in one place to read now, not save for later. RSS is a pretty ancient "technology", yes, but nobody has invented anything better yet. I don't believe keeping its code updated would require that much time and effort, and even if it somehow did, then "doing nothing" still sounds like the better option here. Feed reader is not a security threat and so far no attempts at breaching it or sending/ijecting malicious code through it were made. I'm not sure if the removal of feed reader is going to affect any extensions as I believe most use their own querying system but it definitely sends a message.

There are quite a few WebExtensions supporting feeds, and online readers/services and so on. I personally moved to one of these extensions, and my feed handling improved, it's just better. Other devs will also create new extensions and port some from Chrome. So, it's far from dead, on the contrary it's moving from old code unable to parse and support modern improvements, to some modern parsing libraries and support. Anyway the process you fear will happen is already happening from quite some years, since the browser having the majority of the market share never had native support. (In reply to jaramat from comment #2) > I don't believe keeping its code updated would require that much time and > effort Unfortunately you are wrong, this code is old and bogus, it has quite a few security problems, and prevents a bunch of optimizations from happening. It's not sustainable and nobody wants to maintain it in current shape, nor we have the resources to write it from scratch (and maintain it then).

(In reply to Marco Bonardo [::mak] from comment #3) > (In reply to jaramat from comment #2) > > I don't believe keeping its code updated would require that much time and > > effort > > Unfortunately you are wrong, this code is old and bogus, it has quite a few > security problems, and prevents a bunch of optimizations from happening. > It's not sustainable and nobody wants to maintain it in current shape, nor > we have the resources to write it from scratch (and maintain it then). Agreed. The feed discovery and parsing code is appalling, and uses a whole pile of platform features that I want very much to remove. It either needs to go away or be more or less entirely rewritten.

If this happens, let's plan how to message users of feed reader and live bookmarks through HB with an add-on to replace the functionality

(In reply to Tyler Downer [:Tyler] from comment #5) > If this happens, let's plan how to message users of feed reader and live > bookmarks through HB with an add-on to replace the functionality There's no "if". This is happening, probably before the end of the 64 cycle.

Than even more important. Let's make sure that's part of the planning.

Can Firefox Live bookmarks functional be re-implemented as extension via WebExtensions API, via same way like in Google Chrome? Example of Google Chrome extension, that emulate Firefox Live Bookmarks feature: https://chrome.google.com/webstore/detail/foxish-live-rss/jpgagcapnkccceppgljfpoadahaopjdb

I create feature request in Foxish live RSS Google Chrome extension for port it to Firefox: https://github.com/davidhampgonsalves/foxish/issues/6

(In reply to Murz from comment #8) > Can Firefox Live bookmarks functional be re-implemented as extension via > WebExtensions API, via same way like in Google Chrome? Yes, absolutely, there are already a few addons doing it on addons.mozilla.org.

ehr, I must be more specific, there are a few add-ons implementing rss feed parsing and readers, no the actual "live bookmark" thing. But honestly there's not much value in how we implemented live bookmarks as bookmarks.

On the contrary, abusing the bookmark system is the only reasonable way to get links in a drop down menu per site, because web extensions can only create a single button. A possible alternative would be to create a new extension for every RSS feed in existance but that would mean every user has to upload several private extensions to AMO and I am sure you don't want that.

(In reply to Tyler Downer [:Tyler] from comment #5) > If this happens, let's plan how to message users of feed reader and live > bookmarks through HB with an add-on to replace the functionality As noted in the last section of the doc in the user story, we'll notify users once the removal takes effect. I think we expect to open a SUMO page on startup at that point - not using heartbeat (which I assume is what "HB" means?). The SUMO page can recommend replacement add-ons. We'll liaise with the AMO folks for a list of recommendations once we get to that point. bug 1477674 covers creating the page. Does that address your concerns? If you think that plan needs significant changes, can we discuss that outside of this meta bug, which isn't really the best place for the discussion?

(In reply to Alistair Buxton from comment #12) > On the contrary, abusing the bookmark system is the only reasonable way to > get links in a drop down menu per site, because web extensions can only > create a single button. No, it's not the only reasonable way. That single button can have menus and submenus, or other fancy views. As well as an add-on can create a hierarchy in a content page. Feedbro does that in content for example, but nothing would prevent to do the same in the popup.

(In reply to Alistair Buxton from comment #1) > The core functionality works - you can subscribe to a feed using the options > page and the bookmarks will be created. The rest does not work due to > apparently unimplemented functions in Firefox extensions API. If you have concerns about specific missing webextension features, please file a separate webextension bug with more details; this isn't the right place to get those addressed.

(In reply to Marco Bonardo [::mak] from comment #14) > (In reply to Alistair Buxton from comment #12) > > On the contrary, abusing the bookmark system is the only reasonable way to > > get links in a drop down menu per site, because web extensions can only > > create a single button. > > No, it's not the only reasonable way. > That single button can have menus and submenus, or other fancy views. As > well as an add-on can create a hierarchy in a content page. Feedbro does > that in content for example, but nothing would prevent to do the same in the > popup. As you are no doubt well aware, neither of the methods you describe allows me to create one button per feed from a single extension, because extensions cannot create more than one browser action.

(In reply to :Gijs (he/him) from comment #13) That's good enough, unless we feel users should be notified ahead of the removal. Let me know if we do

So my comment is tagged as advocay and collapsed by default. Is there another place where I can request reconsidering removal of this functionality?

I'm sorry, but the removal will happen regardless, we already considered all the possibilities. Thank you for your feedback.

Hi, everyone - Mike Hoye here, Mozilla's engineering community manager. I realize that the people who care at all about RSS care about it a lot - I run Planet Mozilla, so I have some skin in this game - but at this point this decision is made; this isn't functionality that we can continue to support. For what it's worth, I liked this feature too and I'll be sad to see it go, but I think that's the right decision. There are a bunch of excellent stand-alone readers out there, and I encourage those of you who are invested in this to look into feedreader or add-on alternatives. They really are a better experience, though they're a few extra clicks away. If the current state of the WebExtensions API doesn't meet your needs, to file bugs that request the functionality you need. But for the reasons articulated in this bug, among others, this decision has to stand, and if this bug turns into a pile-on, I'm going to need to lock it down.

As requested, here are two bug reports which detail missing functionality required to re-implement live bookmarks without abusing the bookmark system; one of them is a year old, the other I've just reported and may be a duplicate, but search didn't find anything similar. https://bugzilla.mozilla.org/show_bug.cgi?id=1362741 https://bugzilla.mozilla.org/show_bug.cgi?id=1478781

Please consider replacing the livemarks with bookmarks to the feed instead of the site. Feeds are delivered via http(s), and as such should be bookmark'able by Firefox. If usage statistics are correct, its quite probable that this minority of unusual users prefers to keep a bookmark to the feed over one to the site. IOW, the migration should be in a way that it suits the users using the feature today, and not some random user not using it. Pointing the new normal bookmarks to the feed would also solve the issue that today addons cannot access livemarks (see bug 1276821, which now is probably going to suffer the same fate as bug 1382691). When livemarks become normal bookmarks, a simple addon could access them, and provide user-friendly rendering, without the need for a WebExtension. Maybe an addon could even feed the content of the feeds to the Firefox Homepage.

I admit, I was rather **** at Mozilla when I first read about this. But I have been using Feedbro for the past few hours and it's actually rather superior to Live Bookmarks.

Spencer, this is a bug tracker, not a place for conversations, that's why such comments are off-topic. If you want, you can start a discussion on a forum or a mailing list, which is a better place than Bugzilla.

(In reply to Carl Eike Hofmeister from comment #28) > Please consider replacing the livemarks with bookmarks to the feed instead > of the site. I tend to disagree. the reason to use a bookmark to the site uri, instead of the feed uri, is that with the removal of the feed preview, clicking on that bookmark will open an unreadable xml, that is pointless to most users. As explained in the document, we'll export the feed uris to the opml format supported by most rss clients and addons.

Another blocking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1246236 The long standing issue where live bookmarks can't be pulled from a file:// URI can now not be fixed until web extensions get filesystem access.

(In reply to Marco Bonardo [::mak] from comment #33) > (In reply to Carl Eike Hofmeister from comment #28) > > Please consider replacing the livemarks with bookmarks to the feed instead > > of the site. > > I tend to disagree. the reason to use a bookmark to the site uri, instead of > the feed uri, is that with the removal of the feed preview, clicking on that > bookmark will open an unreadable xml, that is pointless to most users. > As explained in the document, we'll export the feed uris to the opml format > supported by most rss clients and addons. I've been using a separate feed reader for several years, and I would also continue to use and appreciate feed discovery in Firefox on an ongoing. I understand that removal of live bookmarks makes sense and is going ahead, but I would also suggest that feeds deserve acknowledgement and exposure/discovery in the browser that has traditionally championed open standards of data publishing and consumption. Being able to see that a page has feeds and to copy their URLs in the future would significantly aid those of us who do use feeds/separate feed readers as we add newly-found feeds. Would this be something that could be implemented (relatively) simply?

A WebExtension add-on can surely do what you want.

(In reply to Marco Bonardo [::mak] from comment #37) > A WebExtension add-on can surely do what you want. I expect so (I'll be looking for one soon :) ), but my intention was to suggest that not entirely eradicating the concept of feeds from vanilla Firefox would be A Good Thing. Separate to the convenience factor for those of us who use feeds, there's the concern of further burying/killing feeds in general. From a previous comment: > [...] this move might prompt more website administrators to stop offering RSS feeds at all. Life is getting harder as it goes for an RSS user like me, and this puts another nail in the coffin. I see feeds as integral to a web that isn't overly reliant on centralisation around a few popular-at-the-current-time services, such as Twitter and Facebook, and would have loved to see Firefox provide for discovery of their URLs, rather than completely "hiding" them. But then I suppose feed usage is so low this is all rather irrelevant. :/ Thanks for reading, anyway. :)

Just to understand: 1. if I press <Ctrl+i> on https://en.wikipedia.org/wiki/Main_Page , will I see an RSS icon? 2. If someone sends me a link to an RSS feed, will Firefox guide me (at least with "RSS subscription -- you need an extension to see this") or will it just display human-unreadable XML (as Chrome does)?

It will work the same as Chrome. If someone sends you a link to an xml, they suppose you know what it is and how you can use it (as you said, with any other browser you'd get an unreadable xml). At that point you can just add it to the add-on managing feeds. Similarly, an add-on can analyze a page to detect the existence of feeds, and work more or less like the current "Subscribe to" menu (for example Feedbro has a Find Feeds in Current Tab option). At that point if I know you have no idea what a feed is, I'd probably send you the link to the site homepage and suggest you to use the add-on.

Hello Marco, (In reply to Marco Bonardo [::mak] from comment #40) > If someone sends you a link to an xml, they suppose you know what it is and > how you can use it (as you said, with any other browser you'd get an > unreadable xml). Can I give suggestions or are they off-topic? The "RSS/atom feed icon" is still present on many many sites in the "follow us" section. If a user clicks on it, the worst possible experience is getting a wall of unreadable XML ("Is the site broken? Is the browser broken?"). A simple message ("Hey, Firefox can't use this, but [there are add-ons](https://addons.mozilla.org/en-US/firefox/search/?q=feed+reader)!) would go a long way in improving the UX, while hopefully adding very little code to maintain in Firefox. Do you think this is possible?

I'd lean towards still treating feed content types as externally-handled. We're working on an extension API which will allow them to handle that automatically, but for people without feed reader extensions who have external feed readers, I think that may give better results. (In reply to Francesco Ariis from comment #41) > Hello Marco, > > (In reply to Marco Bonardo [::mak] from comment #40) > > If someone sends you a link to an xml, they suppose you know what it is and > > how you can use it (as you said, with any other browser you'd get an > > unreadable xml). > > Can I give suggestions or are they off-topic? Suggestions like this are within the scope of the bug, and very much welcome. Thanks.

As far as I can tell there are three "parts" of the feed reader and live bookmarks support in Firefox: 1. ("Graphical display of feed"). When you go to the URL corresponding to the RSS or Atom feed itself (e.g. https://blog.mozilla.org/feed/), Firefox recognises the XML file at that location as a feed, parses it and displays it nicely as a pseudo-webpage. You can end up on such a URL, for instance by clicking on a "RSS/atom feed icon" within a page (as noted above (Comment #41)), or by clicking on the "Subscribe" toolbar in the Firefox UI (see 3, below). 2. ("Live bookmarks"). When you have a "live bookmark" of a feed, and navigate to the submenu corresponding to it, then Firefox parses the feed (presumably with some caching) and displays the entries from the feed as bookmarks within that submenu. 3. ("Feed detection"). When you navigate to a page which has a feed (or feeds) associated with it (e.g. https://blog.mozilla.org), Firefox will detect that and inform you by ungreying the "Subscribe" button in the toolbar. If you click on that button then you're either navigated to the feed or, if there's more than one, the feeds are listed so that you can navigate to them, by clicking. Do I understand correctly that all three of these are slated to be removed? > Suggestions like this are within the scope of the bug, # My suggestions ## Navigation to feed URLs (raised above in #41) > A simple message ("Hey, Firefox can't use this, but [there are add-ons](https://addons.mozilla.org/en-US/firefox/search/?q=feed+reader)!) would go a long way in improving the UX, while hopefully adding very little code to maintain in Firefox. > I'd lean towards still treating feed content types as externally-handled. We're working on an extension API which will allow them to handle that automatically, but for people without feed reader extensions who have external feed readers, I think that may give better results. If feasible, I personally would prefer if it were possible to view the raw XML of the feed directly within Firefox — it's annoying when there's a resource that could easily be viewable in Firefox, as it's text only, but Firefox forces me to use an external application (this happens with vCalendar files). Since Firefox's folding/collapsing of XML is quite nice, it would be a particular shame in this case. OTOH the possibility of opening the feed with an external application would also be very convenient, so IMO the ideal option might be to display the raw xml (as for any such xml file), but instead of the standard "This XML file does not appear to have any style information associated with it. [...]" header, have an informational message (similar to the one suggested by Francesco Ariis), plus a button allowing you to handle the feed externally (i.e. something similar to the current UI, but without the option of subscribing with live bookmarks, and without "graphically" displaying the actual feed). Unfortunately, this would probably require a non-zero, if small, amount of parsing the XML file to determine that it describes itself as an RSS/Atom feed. ## The "Subscribe" button in the Firefox UI Would it be possible to keep the "Subscribe" button that can be placed in the toolbar, possibly without feed auto-detection? > Agreed. The feed discovery [...] code is appalling, and uses a whole pile of platform features that I want very much to remove. It either needs to go away or be more or less entirely rewritten. (I'm not sure how heavy the feed detection code needs to be — AFAICT it just has to find "link" elements with the rel="alternate" attribute and either of the "application/rss+xml" or "application/atom+xml" types, in the header of the page. OTOH having to run such code on every single page, to auto-detect, does add some overhead.) If the overhead of auto-detection is too high, the "Subscribe" button could never be greyed out, and the feed detection could only run when you click the button. The feed(s) would be listed (as is the case now for multiple feeds) or the user informed that no feeds are available. Like now, clicking on a feed would navigate to the corresponding URL.* The advantage of a button in the toolbar, over relying on websites to display them, is that it provides a consistent interface (you don't have to search for the subscribe button) and that many websites that have an RSS/Atom feed still don't actually provide a subscribe button (without pointing any fingers, https://blog.mozilla.org doesn't AFAICT :p ). The advantage of this being built-in functionality, rather than being provided by a webextension (which would probably be trivial to implement) is that it gives greater discoverability to RSS/Atom feeds as an idea, and provides "moral" support to them, at relatively little cost (a dozen lines of code and an icon in the customise menu). Many people have written why feeds are an extremely valuable part of the web, so I won't elaborate on this. FWIW I had first discovered feeds by looking around Firefox's UI. :) * Obviously, this depends on Firefox providing some (limited) options once you navigate to the URL — see the previous section.

(In reply to plaice.adam+persona from comment #43) > "Graphical display of feed", "Live bookmarks", "Feed detection" > > Do I understand correctly that all three of these are slated to be removed? Yes. > If feasible, I personally would prefer if it were possible to view the raw > XML of the feed directly within Firefox <snip> > OTOH the possibility of opening the feed with an external application would > also be very convenient, so IMO the ideal option might be to display the raw > xml (as for any such xml file), but instead of the standard "This XML file > does not appear to have any style information associated with it. [...]" > header, have an informational message (similar to the one suggested by > Francesco Ariis), This is covered by bug 1479038. > plus a button allowing you to handle the feed externally > (i.e. something similar to the current UI, but without the option of > subscribing with live bookmarks, and without "graphically" displaying the > actual feed). Nobody has an application like this unless they have manually installed client-side feed software, and can also install an add-on (either separately or as part of such software). So the argument against having this be an add-on ("users have to install more things") doesn't really apply. The userbase for such a builtin button would be even smaller than the current userbase for RSS within Firefox generally (most people seem to use things like ttrss or other online services these days). There are also security risks involved with having a button like this in web content that opens arbitrary local applications (and putting it outside of web content makes it more work to have the UI appear/disappear at the right time because then it requires more process communication about when to show/hide the message). Finally, we have UI for this today in the feed preview (and you can in theory set it up to always use the same client application for subscriptions, without showing the feed preview page) but I don't know of any apps that work. Even Thunderbird's support is broken, and has been for years, and as far as I know nobody has bothered to complain about this until now - when we're removing the (broken) UI. I think there might be an old inactive bug on file about it that nobody's ever bothered to fix, but I couldn't find it even after spending considerable time looking for it. It's the same with the web side of things - subscribing through a website started off (back in Firefox 2) with support for 3 readers - google reader, bloglines and "my yahoo!". The former 2 have been removed over the years. AFAIK nobody has ever suggested adding anything else. I think this should be provided by an add-on. That way it can be properly tested and supported and is provided only for users who use it, without cluttering up the UI for everyone else. > ## The "Subscribe" button in the Firefox UI > The advantage of this being built-in functionality, rather than being > provided by a webextension (which would probably be trivial to implement) is > that it gives greater discoverability to RSS/Atom feeds as an idea, The button hasn't been part of primary UI since Firefox 4 (for the past 8 years). This isn't "discoverable" for users, and the notion (or benefit) of subscribing to a page is not easily grasped. Once (very very very few) people see a feed preview page, only 4% of people attempt to subscribe to the feed. That's a *terrible* rate of helping people "discover" the usage of feeds, even for people who have already managed to click an in-content link, "subscribe to this page" menu entry, or find the button and move it to primary UI (which are also incredibly rare). > and provides "moral" support to them, at relatively little cost (a dozen lines > of code and an icon in the customise menu). It would be significantly more than this. You need code to specify the button, whether it's customizable, what it does when clicked (including showing a popup as necessary), you need code to propagate state from the content process (which has access to the website) to the parent (which has the button), you need to make sure that state updates correctly when the user switches, detaches/re-attaches, navigates and closes tabs, you need to think about how to handle frames, about how to deal with websites that specify so many feeds that the dropdown overflows, you need to make sure it works in the overflow menu when the window is narrow / the button gets customized there, you need a keyboard-accessible alternative for non-mouse users, ... And then you need automated tests for the above to make sure you don't break it, e.g. when working on Fission (process-per-site). That's a lot of work for "moral support". And for that we'd have UI ship with the browser that provides users with links to pretty-printed XML (or a dialog asking them what they want to open this .xml/.rss/.atom file with, having no idea what it is). Even with the disclaimer at the top of the XML file that tells users how to make the content more readable, that's clearly not a great UX. So I'm pretty convinced that shipping this with Firefox by default is not the right choice.

How will users existing live bookmarks be handled? Will they be removed from the users bookmarks or will they just link to the RSS feed XML file? What steps if any will be taken to allow users to migrate their existing live bookmarks to a web extension?

(In reply to Spazturtle from comment #45) > How will users existing live bookmarks be handled? Will they be removed from > the users bookmarks or will they just link to the RSS feed XML file? > > What steps if any will be taken to allow users to migrate their existing > live bookmarks to a web extension? It's described in details at the top of the bug, in the User Story (export to OPML, switch to normal bookmark, warn the user).

Made this add-on as a replacement: https://addons.mozilla.org/firefox/addon/livemarks/

Livemark is great solution and good replacement for removed build-in live bookmarks feature, thank you so much!

Hi, everyone. Tim's put "livemarks" up - thanks, Tim! - and our addons team is doing some outreach to the various developers who offer comparable addons in the Chrome ecosystem - thanks Cait! - to ask if we can help them bring those webextensions into the Firefox ecosystem. I realize that this is a contentious decision, but it's also a decision that's been made; it won't quite be a seamless experience, but people will be able to keep this functionality and the result will be a safer and more stable Firefox. For the time being I'm going to throttle comments on this bug. If that's a problem, or if you've got something to add to this bug that will materially move it towards completion, please let me know.

(In reply to :Gijs (he/him) from comment #44) > (In reply to plaice.adam+persona from comment #43) > > "Graphical display of feed", "Live bookmarks", "Feed detection" > > > > Finally, we have UI for this today in the feed preview (and you can in > theory set it up to always use the same client application for > subscriptions, without showing the feed preview page) but I don't know of > any apps that work. Even Thunderbird's support is broken, and has been for > years, and as far as I know nobody has bothered to complain about this until > now - when we're removing the (broken) UI. I think there might be an old > inactive bug on file about it that nobody's ever bothered to fix, but I > couldn't find it even after spending considerable time looking for it. As far as Thunderbird goes, if it is added as an external app, it certainly *does work* to subscribe the feed and has for a long time (I'm the Tb feed peer). I'm sure others work(ed) as well; it's simply a case of passing the url prefaced with feed: as an arg to the executable. Give it a try.. (Do not start Tb with -no-remote). In any event, it's very sad to see an open, unwalled publishing method like feeds be removed from discoverability (whatever the level of UX polish currently), for large reasons. I hope bug 1479038 keeps at least the simple ability to send a web page's advertised feed link(s) to an external app. Perhaps telemetry could tell us something about how many websites there are that want to advertise their feed content by embedding links; this group shouldn't be abandoned. Regarding the preview code -- I do agree it's a maintenance problem and would need a rewrite, which is why bug 450543 to take it in Tb was wontfixed.

(In reply to alta88 from comment #51) > (In reply to :Gijs (he/him) from comment #44) > > (In reply to plaice.adam+persona from comment #43) > > > "Graphical display of feed", "Live bookmarks", "Feed detection" > > > > > > > Finally, we have UI for this today in the feed preview (and you can in > > theory set it up to always use the same client application for > > subscriptions, without showing the feed preview page) but I don't know of > > any apps that work. Even Thunderbird's support is broken, and has been for > > years, and as far as I know nobody has bothered to complain about this until > > now - when we're removing the (broken) UI. I think there might be an old > > inactive bug on file about it that nobody's ever bothered to fix, but I > > couldn't find it even after spending considerable time looking for it. > > As far as Thunderbird goes, if it is added as an external app, it certainly > *does work* to subscribe the feed and has for a long time (I'm the Tb feed > peer). I'm sure others work(ed) as well; it's simply a case of passing the > url prefaced with feed: as an arg to the executable. Give it a try.. (Do not > start Tb with -no-remote). I doublechecked before I wrote that comment, and did again now. I can't recall it ever working for me (on 3 different machines, over the years), I've always had to copy the URL and paste it in the subscribe... dialog in TB. Tested on macOS. I open TB via the dock or spotlight, so no additional params go to the .app . Anyway, this is not the right place for diagnosing that issue. > In any event, it's very sad to see an open, unwalled publishing method like > feeds be removed from discoverability (whatever the level of UX polish > currently), for large reasons. I hope bug 1479038 keeps at least the simple > ability to send a web page's advertised feed link(s) to an external app. That bug is specifically about changing the XML pretty printing for feeds, so it won't have anything to do with detecting feed <link>s in pages. > Perhaps telemetry could tell us something about how many websites there are > that want to advertise their feed content by embedding links; this group > shouldn't be abandoned. We don't have plans to keep the feed-on-webpage-discovery portion. There are a number of problems with trying to do so, as I outlined in the parts of comment 44 you didn't quote.

(In reply to alta88 from comment #53) > (In reply to :Gijs (he/him) from comment #52) > > (In reply to alta88 from comment #51) > > > Perhaps telemetry could tell us something about how many websites there are > > > that want to advertise their feed content by embedding links; this group > > > shouldn't be abandoned. > > > > We don't have plans to keep the feed-on-webpage-discovery portion. There are > > a number of problems with trying to do so, as I outlined in the parts of > > comment 44 you didn't quote. > > It's clear you've made a decision and what remains is constructing a > goal-seeked narrative. I'm not "constructing" a narrative, I'm repeating to you arguments made and discussions had prior to the decision you're questioning. Your suggestion also implies there is some other "secret" motivation for this that we're not telling you (or that we do things randomly, with no reason), and the implied assumption of bad faith there is not OK. > Not bothering to want to know how many sites want to distribute content via > feeds is sad. It's in fact unusual to remove a feature without having > conclusions based on data. We did collect data - about how users use feeds (including subscriptions), rather than how websites advertise them. That's what the removal is based on because it's the more relevant factor here. To recap some of comment 44, almost no users subscribe to feeds. It isn't cheap to maintain. If we removed everything else and kept the subscription/discovery UI, that'd be a half-broken feature ("road to nowhere" without some third-party app/website/add-on). Low usage, non-trivial cost, almost no reward - that's a straightforward decision to make.

(In reply to :Gijs (he/him) from comment #54) > (In reply to alta88 from comment #53) > > It's clear you've made a decision and what remains is constructing a > > goal-seeked narrative. > > I'm not "constructing" a narrative, I'm repeating to you arguments made and > discussions had prior to the decision you're questioning. Your suggestion > also implies there is some other "secret" motivation for this that we're not > telling you (or that we do things randomly, with no reason), and the implied > assumption of bad faith there is not OK. As a side note, comments like these are the reason comments were restricted in this bug. If you continue in this vein, you seriously risk losing your editbugs privileges.

Ok, that's enough of that. Once again, while we realize that this is a contentious decision, it is also a decision that's been made. Alternatives have been provided, both in-product via a web-extension and externally, and we have no reason to re-litigate this decision. Please consider this a polite reminder that this editbugs-privileged-users-only discussion is effectively resolved. Anyone who would like to continue this discussion in a way that does not meaningfully advance this bug towards that resolution will find their comments, and possibly their ability to make comments, subject to immediate moderation. If you have concerns about that, you're welcome to email me directly. Thank you.

Flagging for addition to release notes when this ships.

Added to 64beta relnotes: Support for RSS preview and live bookmarks is being removed

Posted site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2018/rss-atom-feed-preview-has-been-removed/

Ok... Just had issues looking at RSS feed and I thought it was my Web hosters having issues. What's the alternative to view RSS feeds in Firefox instead of having it download the Rss feed ? Is it possible to get the feature back with a WebExtension ?

You can find a curated list of add-ons here https://addons.mozilla.org/firefox/collections/mozilla/refined-reading/

(In reply to Marco Bonardo [::mak] from comment #61) > You can find a curated list of add-ons here > https://addons.mozilla.org/firefox/collections/mozilla/refined-reading/ Thanks :)

64 was released, so this is done now.