nsIDebug.idl, nsITraceRefcount.idl not frozen, but part of the SDK

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
14 years ago
7 years ago

People

(Reporter: Biesinger, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

nsIDebug.idl and nsITraceRefcount.idl are part of the SDK, but not marked frozen.

since they are @status UNDER_REVIEW, maybe they should just be marked frozen?

Comment 1

14 years ago
Yes, these must be marked frozen.  Moreover, we have NS_GetDebug and
NS_GetTraceRefcnt that need to be marked frozen if they are not already marked
as such.  There may be a few other functions in nsXPCOMPrivate.h that need
similar loving.

Comment 2

14 years ago
I believe we should definitely freeze nsIDebug the way it is. Is nsITraceRefCnt
debug-only? I'm a lot less certain about that one.

Comment 3

14 years ago
i do not think nsITraceRefcount or nsIDebug.idl should be part of the SDK.  I
remember adding this as a private interface between the xpcom library and the
xpcom glue library -- something not intended for general use by developers.

Comment 4

14 years ago
If the glue uses them, they need to be frozen, since changing them would break
old clients of the glue. We could do @status FROZEN + PRIVATE

Comment 5

14 years ago
Or, are these interfaces only needed in --enable-debug builds?  Can we make them
not be used when the glue is compiled with MOZILLA_STRICT_API?

Comment 6

14 years ago
@status FROZEN + PRIVATE is fine with me...  something can be frozen and not put
into the public SDK.  

Darin is also right, these are only used in debug (or only should be used when
in a debug bug).  I do not see how MOZILLA_STRICT_API has anything to do with
this.  

Comment 7

14 years ago
> Darin is also right, these are only used in debug (or only should be used when
> in a debug bug).  I do not see how MOZILLA_STRICT_API has anything to do with
> this.  

Doug: effective a month or so ago, we now build the two versions of glue library
that are included in the SDK with MOZILLA_STRICT_API defined.  that was done so
that those glue libraries would use the frozen string API.  however, the glue
library that is linked into libxpcom_core (or libxul), is compiled against the
unfrozen internal string API.  this was also done so that external components
could be linked cleanly against libxpcom_glue.a + libxpcom.so.

So, this means that we could #ifdef the glue code to only use nsIDebug and
nsITraceRefcnt when MOZILLA_STRICT_API is not defined.  This seems like a good
idea to me because it is likely that users of the Gecko SDK may themselves
#define DEBUG for their own users.  If our headers see that and start using
nsIDebug or nsITraceRefcnt, then that could cause problems.

Make sense?

Comment 8

14 years ago
so, i want to write a xpcom component using MOZILLA_STRICT_API.  during
development, i want to see if I am leaking and if so, do something about it. 
what you are proposing would have me disable MOZILLA_STRICT_API.  

Comment 9

14 years ago
Well, we could always have another #ifdef that selectively enables
nsITraceRefcnt and/or nsIDebug, but unless we are going to freeze those
interfaces, then it seems like they should not be used when MOZILLA_STRICT_API
is defined.

Comment 10

14 years ago
Those interfaces are being used between the xpcom glue library and the xpcom
library -- not by the user.  The class, nsDebug and nsTrace(something), use them
internally.

Comment 11

14 years ago
> Those interfaces are being used between the xpcom glue library and the xpcom
> library -- not by the user.  The class, nsDebug and nsTrace(something), use 
> them internally.

Yes, but that does not change the fact that a consumer's binary (component or
exe) will have a dependency on those interfaces.  Therefore, we cannot change
those interfaces, and they are effectively frozen.  So, either we freeze them or
we make it so that by default consumers do not "use" them (by linking to a
static library that uses them or otherwise) when they say that they only want to
use frozen interfaces (i.e., when they define MOZILLA_STRICT_API).

Comment 12

14 years ago
Darin -- my point is, they are frozen and they are not part of the SDK for
general use. MOZILLA_STRICT_API should not hide these two interfaces.
QA Contact: xpcom

Comment 13

11 years ago
mass reassigning to nobody.
Assignee: dougt → nobody

Comment 14

7 years ago
Does anyone know if this interface was removed?  I am unable to make a reference to it from javascript although the article  https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIDebug it says that it is scriptable.

Comment 15

7 years ago
Components.classes["@mozilla.org/xpcom/debug;1"].getService(Components.interfaces.nsIDebug) WFM in nightlies. And this bug, being about frozen interfaces, is no longer useful since we no longer have frozen interfaces.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME

Comment 16

7 years ago
Thanks, Benjamin.  I was hope that this interface allowed me to debug javascript but it only crashes Firefox.
You need to log in before you can comment on or make changes to this bug.