Comment 150 for bug 25830

(In reply to comment #123)
> Why, though? What's the use case for a null aData?

Well, when the handler has no data... f.ex. when wanting to redispatch in
onStartRequest... (do we expect embeddors to implement nsIExternalHelperAppService?)

> If we do plan to just keep this an exthandler-specific hack, it may be better
to just expose
> that interface on aContext (basically have the object implementing the
nsIDispatchable
> interface be the context, and have it forward to the original context as
needed). Then the
> interface could be in a .h file altogether or something, with all
documentation in that file.

Hm, yeah, that's also possible. Maybe that's better for now.

> It's a good precondition, but again only one that makes sense if we plan to
have multiple
> handlers that get an nsIDispatchable. If we do, then a lot of these comments
make more
> sense...

This is the question... I certainly considered that case; but is it something we
really want to do?

If we want to ever replace nsIExternalHelperAppService::doContent with
nsIURIContentListener2::doContent (not saying that we want that; just a random
thought), then it does need to have some way to get at the nsIDispatchable.

> It's almost worse, actually. We want to prevent oscillatory bouncing between two
> handlers that both want to fob the load off as the type the other one
handles... So
> extending this to allowing all handlers to redispatch would have to be done
pretty
> carefully.

ah, hmm... to prevent that, we'd need a stack of handlers (or mime types) and
ensure the new type is not in the list...

So I'll probably just use your suggestion of making nsIDispatchable available
off aContext. putting it in a .h would mean it can't be used from a
JS-implemented exthandler; do we want to support that?