169254 - Need some way to pass parentWindow to nsIUriContentListener->DoContent()

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: APIs, enhancement)

Description

[David Epstein]

DoContent() should be accessible from the nsIWebBrowser. Currently there is no
way to pass the parent window to that level. Suggestion is to pass it from uri
content listener to the web browser using a get method. Also, the isPrefered
info needs to be associated with the parent window.

Comment 1

[David Epstein]

CanHandleContent() info also needs to percolate up to the parent.

Comment 2

[Judson Valeski]

David, can you ellaborate here? Why should DoContent() be accessible from there?

Comment 3

[David Epstein]

cc'ing mscott for more info. As I understand it, uri content handler methods
should be accessible from either the uri loader or the web browser object. The
web browser can have an associated DOM, but nsIURIContentListener methods don't
pass any DOM objects. There's no direct way to hook up the content listener to a
parent window. Since this iface is frozen, parameters can't be added to it. But
Rick suggested this could be done under the hood in nsURILoader.cpp. 

Before DoContent() is called, the uri loader looks to see if there is a
preferred content type handler. If so, then in calls IsPreferred(). If the
content type isn't specified, it calls CanHandleContent() to see if the listener
can handle it. Then DoContent() is called to 'handle' it (via stream lstnr to
consume the data). Currently, DoContent is passed a request object to facilitate
this. My suggestion was for a more direct way for content handling in a parent
or child window.

Comment 4

[Darin Fisher]

mass reassign of various rpotts bugs to me

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm.... I'm still not sure what the request is here.  It sounds like the
listener wants to access some window object.  What window object?  The one that
originated the load?  Or some object associated with the listener itself?

Comment 6

[David Epstein]

I believe this has to do with the window handling the load, where DoContent() is
triggered. But the window where the link was clicked might also be useful to be
associated with the content listener.

Comment 7

[Boris Zbarsky [:bzbarsky]]

The api is frozen; we'd need to rev it to do anything like this (something I've
been considering anyway, by the way).

Comment 8

[Benjamin Smedberg]

Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.