Closed
Bug 327245
Opened 19 years ago
Closed 10 years ago
Consider sharing the mJSPrincipals-management code in a superclass
Categories
(Core :: Security: CAPS, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1163254
People
(Reporter: bzbarsky, Assigned: dveditz)
Details
We have some copy/pasted mJSPrincipals stuff in nsPrincipal, nsSystemPrincipal, and nsNullPrincipal... we should really not have that, imo.
Updated•15 years ago
|
QA Contact: caps
Comment 1•13 years ago
|
||
With the bug 728250 fixed it should be easier to fix this bug as the code can just put AddRef/Release implementation to nsJSPrincipals that becomes a base class for all relevant classes. However, that would require to give up on NS_DECL_ISUPPORTS_INHERITED and explicitly declare QueryInterface in the subclasses. Is it fine?
Reporter | ||
Comment 2•13 years ago
|
||
Actually, you could just use NS_IMPL_ADDREF_INHERITED and NS_IMPL_RELEASE_INHERITED in the subclasses (and that's what you'd want anyway) and do all the refcounting in the superclass.
Comment 3•13 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #2)
> Actually, you could just use NS_IMPL_ADDREF_INHERITED and
> NS_IMPL_RELEASE_INHERITED in the subclasses (and that's what you'd want
> anyway) and do all the refcounting in the superclass.
That is not ideal as it still bloats the subclasses with an extra method definition. I was hopping for a macro that allows to define just the QI method in the subclasses so only nsJSPrincipals will have AddRef/Release.
Reporter | ||
Comment 4•13 years ago
|
||
> as it still bloats the subclasses with an extra method definition.
That's desired in this case, to some extent, because it allows leak logging to know which subclass leaked.
Comment 5•13 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #4)
> > as it still bloats the subclasses with an extra method definition.
>
> That's desired in this case, to some extent, because it allows leak logging
> to know which subclass leaked.
But that can be solved with a log-only virtual method like getLogClassName() that returns the desired class name. That would also allow to implement nsJSPrincipals::Destroy, https://hg.mozilla.org/mozilla-central/file/b9a624c9fdbe/caps/src/nsJSPrincipals.cpp#l64 , without using AddRef/Release hack as the method can just call the destructor after calling NS_LOG_RELEASE(this, 0, getLogClassName());
Comment 6•10 years ago
|
||
Forward-duping to bug 1163254, where I'm cleaning some of this stuff up.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•