Background

In Feed Handling/Type Determination the type sniffing of web feed documents was discussed. When a feed is discovered, its type is coerced to application/vnd.mozilla.maybe.feed. This is a type that not handled internally by Gecko. As a result, the "embedding" Firefox application must register that the docshell loading pages actually can handle it, using a special stream converter that handles the various actions associated with feeds.

Content Listeners

The browser front end needs to tell the embedded docshells (one per tab) that they can all handle content in the application/vnd.mozilla.maybe.feed type. It does this by registering a "conversion" with the tabbrowser from application/vnd.mozilla.maybe.feed to application/vnd.mozilla.xul+xml. Each <browser> object in the tabbrowser has an implementation of nsIURIContentListener that is the final arbiter of what can and cannot be loaded in that docshell (since the docshell's own content listener consults its parent - the <browser>'s content listener). Once we register the conversion, when the browser's content listener is asked if that type can be handled, it returns that it can, but must be converted to application/vnd.mozilla.xul+xml first.

What this causes is the URI Loader to create a stream converter between the two types. The stream converter handles producing the actual data that is rendered. We want this to be a preview page.

Stream Converter

In browser/components/feeds/src/FeedConverter.js is an implementation of nsIStreamConverter. This converter remembers the supplied listener (which is the docshell that is going to receive and display the data) and then buffers the feed data. Once all the feed data is present, it parses it using the Feed Processor (see bug 325080) and then opens a channel to the XUL feed handler document.

It sets the original URI of the feed handler XUL document to that of the feed itself, so that the appropriate URI shows in the location bar of the browser, and View source shows the source of the feed, not the XUL document.

The parsed Feed Result is stored with the FeedResultService, since there is no direct way for the Stream Converter to communicate with the XUL page that is about to be loaded and so no way for the parsed feed to be sent to it. Using a singleton Feed Result Service means that when it loads, the XUL page can get at the content of the feed and show UI appropriately.

Other Functions

The Feed Converter actually does a few other things, like checking for default handlers that may override the display of the XUL page - such as a default web, desktop application or Live Bookmark handler. In the event that one exists, it performs that action rather than displaying the XUL page.