There are a few bugs in the way Firefox handles content at present. They are at various levels. One of them is that the docshell for the <browser> does not ask its parent content listener (the content listener maintained by browser.js) if it is the preferred handler for specific content types. The upshot is that the browser (the "embeddor") cannot specify that certain special content types (e.g. application/vnd.mozilla.maybe.feed) are actually handled "internally" by the browser page - e.g. for pretty print. The parent listener needs to be consulted so that a type conversion can be specified.

This patch to nsDSURIContentListener::CanHandleContent consults the "parent" listener for any content type conversions that may apply.

So... This is actually an API change, effectively. That makes me pretty unhappy with it (nsIURIContentListener is a frozen api), much less on the 1.8 branch. It basically feels like we're overloading isPreferred in a rather odd way....

Should I be calling parent->CanHandleContent instead? That seems more reasonable, given the documentation in nsIURIContentListener.idl...

Is your concern about API change that the Docshell's content listener now consults its parent at all, or that I used the wrong method?

> Should I be calling parent->CanHandleContent instead? That will put you into infinite loops in many cases, so it's even worse. In fact, so might your current patch; I recall at least some content listener impls calling into a child's CanHandleContent from IsPreferred. So yes, the api change is that IsPreferred consults the parent at all. :(

bz told me a better way of registering on IRC: register myself as a application/vnd.mozilla.maybe.feed -> */* converter, and I will be automatically invoked without needting to be in the docshell uri listener hierarchy.