After impl'ing this, I confronted a hanger-on method, GetDOMWindow(), on
nsIWebProgress (which
webbrowser implements, but I'm getting rid of it).
Here are all the uses of nsIWebProgress::GetDOMWindow()
http://lxr.mozilla.org/mozilla/search?string=->getdomwindow
any suggestions on how to get rid of them. Can they get at the DOM window via some
other mechanism?
Jud
Judson Valeski wrote:
> 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
