I've attatched a patch in http://bugzilla.mozilla.org/createattachment.cgi?id=46848 ,
can someone
review?
Thanks,
Jud
Judson Valeski wrote:
> 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
