After talking to Rick Potts and Adam Lock some more about this, we came up w/ the
following
strategy...
The current impl of Add/RemoveWebBrowserListener() is not used, nor do we want to make
it work.
Instead, those methods and their impls will be removed in favor of a more specific
registration
mechanism; such as.
AddWebBrowserListener(nsISupports, nsIID);
The nsISupports, IID mechanism clarifies exactly what listeners we support (inherent
in the IID
arg), and implies that multiple listeners can be added.
Singleton listeners (get/set type listeners, such as URIContentListener,
nsIWebBrowserPersistProgress) will *not* be registerable via this interface as there
are
override semantics that need to maintained. Set*() implies clearing out the old
listener, if
it's called a second time.
Mutli listeners (add/remove type listeners, such as nsIWebProgressListeners) will be
registered
through this interface.
Jud
Judson Valeski wrote:
> http://bugzilla.mozilla.org/show_bug.cgi?id=46848
>
> Suggests that nsIWebBrowser be the root of all listener registration.
> Since filing this, Adam Lock has voiced some concern over it's legitimacy.
>
> Here's nsWebBrowser's impl of the listener registration methods
>
>(http://lxr.mozilla.org/seamonkey/source/embedding/browser/webBrowser/nsWebBrowser.cpp#136)
> and as best I can tell, the array of listeners never gets used.
>
> Currently anyone wanting "progress" adds specific listeners (URIContent,
> webprogress) through explicit methods hanging off of webbrowser, or we
> rely on their objects implementing certain interfaces. This seems a bit
> sloppy to me, and thus I'm inclined to support the root registration
> methods (and to fix 46848).
>
> Adam, can you voice why you believe 46848 should be invalidated?
>
> Jud
