DSURIContentListener should ask parent content listener for content type conversions

RESOLVED INVALID

Status

Core Graveyard
File Handling
RESOLVED INVALID
12 years ago
2 years ago

People

(Reporter: Ben Goodger (use ben at mozilla dot org for email), Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
Created attachment 219044 [details] [diff] [review]
v1: consult the parent content listener

This patch to nsDSURIContentListener::CanHandleContent consults the "parent" listener for any content type conversions that may apply.
Attachment #219044 - Flags: superreview?
Attachment #219044 - Flags: review?
Attachment #219044 - Flags: superreview?(bzbarsky)
Attachment #219044 - Flags: superreview?
Attachment #219044 - Flags: review?(cbiesinger)
Attachment #219044 - Flags: review?
Depends on: 334714
No longer blocks: 324588
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...
Attachment #219044 - Flags: superreview?(bzbarsky)
Attachment #219044 - Flags: review?(cbiesinger)
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.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.