gecko-dev/js/xpconnect/idl/nsIXPConnect.idl
Nika Layzell 14da321a67 Bug 1444745 - Part 5: Update consumers of nsIInterfaceInfo to use the nsXPTInterfaceInfo directly, r=mccr8
Due to the decision to keep the old API on nsXPTInterfaceInfo in part 4, this is
a fairly straightforward patch.

1. I had to change a couple of consumers of `IsRetval()` due to the movement of
that flag.
2. I changed all code which held a nsIInterfaceInfo to hold an `const
nsXPTInterfaceInfo*` instead.
3. I changed code which used the nsIInterfaceInfoManager to instead call the
static methods on nsXPTInterfaceInfo.
2018-04-17 19:20:56 -04:00

382 lines
14 KiB
Plaintext

/* -*- Mode: IDL; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*-
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
/* The core XPConnect public interfaces. */
#include "nsISupports.idl"
%{ C++
#include "jspubtd.h"
#include "js/TypeDecls.h"
#include "mozilla/Attributes.h"
#include "xptinfo.h"
#include "nsCOMPtr.h"
class nsWrapperCache;
%}
/***************************************************************************/
// NB: jsval and jsid are declared in nsrootidl.idl
[ptr] native JSContextPtr(JSContext);
[ptr] native JSObjectPtr(JSObject);
[ptr] native JSScriptPtr(JSScript);
[ptr] native nsWrapperCachePtr(nsWrapperCache);
native JSHandleId(JS::Handle<jsid>);
[ptr] native InterfaceInfoPtr(const nsXPTInterfaceInfo);
/***************************************************************************/
// forward declarations...
interface nsIPrincipal;
interface nsIClassInfo;
interface nsIVariant;
interface nsIObjectInputStream;
interface nsIObjectOutputStream;
/***************************************************************************/
[uuid(73e6ff4a-ab99-4d99-ac00-ba39ccb8e4d7)]
interface nsIXPConnectJSObjectHolder : nsISupports
{
[notxpcom, nostdcall] JSObjectPtr GetJSObject();
};
[uuid(e787be29-db5d-4a45-a3d6-1de1d6b85c30)]
interface nsIXPConnectWrappedNative : nsIXPConnectJSObjectHolder
{
/* attribute 'JSObject' inherited from nsIXPConnectJSObjectHolder */
void debugDump(in short depth);
%{C++
/**
* Faster access to the native object from C++. Will never return null.
*/
nsISupports* Native() const { return mIdentity; }
protected:
nsCOMPtr<nsISupports> mIdentity;
public:
%}
};
%{C++
inline
const nsQueryInterface
do_QueryWrappedNative(nsIXPConnectWrappedNative *aWrappedNative)
{
return nsQueryInterface(aWrappedNative->Native());
}
inline
const nsQueryInterfaceWithError
do_QueryWrappedNative(nsIXPConnectWrappedNative *aWrappedNative,
nsresult *aError)
{
return nsQueryInterfaceWithError(aWrappedNative->Native(), aError);
}
%}
[uuid(3a01b0d6-074b-49ed-bac3-08c76366cae4)]
interface nsIXPConnectWrappedJS : nsIXPConnectJSObjectHolder
{
/* attribute 'JSObject' inherited from nsIXPConnectJSObjectHolder */
readonly attribute InterfaceInfoPtr InterfaceInfo;
readonly attribute nsIIDPtr InterfaceIID;
void debugDump(in short depth);
void aggregatedQueryInterface(in nsIIDRef uuid,
[iid_is(uuid),retval] out nsQIResult result);
};
// Special interface to unmark the internal JSObject.
// QIing to nsIXPConnectWrappedJSUnmarkGray does *not* addref, it only unmarks,
// and QIing to nsIXPConnectWrappedJSUnmarkGray is always supposed to fail.
[builtinclass, uuid(c02a0ce6-275f-4ea1-9c23-08494898b070)]
interface nsIXPConnectWrappedJSUnmarkGray : nsIXPConnectWrappedJS
{
};
/***************************************************************************/
/**
* This is a sort of a placeholder interface. It is not intended to be
* implemented. It exists to give the nsIXPCSecurityManager an iid on
* which to gate a specific activity in XPConnect.
*
* That activity is...
*
* When JavaScript code uses a component that is itself implemented in
* JavaScript then XPConnect will build a wrapper rather than directly
* expose the JSObject of the component. This allows components implemented
* in JavaScript to 'look' just like any other xpcom component (from the
* perspective of the JavaScript caller). This insulates the component from
* the caller and hides any properties or methods that are not part of the
* interface as declared in xpidl. Usually this is a good thing.
*
* However, in some cases it is useful to allow the JS caller access to the
* JS component's underlying implementation. In order to facilitate this
* XPConnect supports the 'wrappedJSObject' property. The caller code can do:
*
* // 'foo' is some xpcom component (that might be implemented in JS).
* try {
* var bar = foo.wrappedJSObject;
* if(bar) {
* // bar is the underlying JSObject. Do stuff with it here.
* }
* } catch(e) {
* // security exception?
* }
*
* Recall that 'foo' above is an XPConnect wrapper, not the underlying JS
* object. The property get "foo.wrappedJSObject" will only succeed if three
* conditions are met:
*
* 1) 'foo' really is an XPConnect wrapper around a JSObject.
* 2) The underlying JSObject actually implements a "wrappedJSObject"
* property that returns a JSObject. This is called by XPConnect. This
* restriction allows wrapped objects to only allow access to the underlying
* JSObject if they choose to do so. Ususally this just means that 'foo'
* would have a property tht looks like:
* this.wrappedJSObject = this.
* 3) The implemementation of nsIXPCSecurityManager (if installed) allows
* a property get on the interface below. Although the JSObject need not
* implement 'nsIXPCWrappedJSObjectGetter', XPConnect will ask the
* security manager if it is OK for the caller to access the only method
* in nsIXPCWrappedJSObjectGetter before allowing the activity. This fits
* in with the security manager paradigm and makes control over accessing
* the property on this interface the control factor for getting the
* underlying wrapped JSObject of a JS component from JS code.
*
* Notes:
*
* a) If 'foo' above were the underlying JSObject and not a wrapper at all,
* then this all just works and XPConnect is not part of the picture at all.
* b) One might ask why 'foo' should not just implement an interface through
* which callers might get at the underlying object. There are three reasons:
* i) XPConnect would still have to do magic since JSObject is not a
* scriptable type.
* ii) JS Components might use aggregation (like C++ objects) and have
* different JSObjects for different interfaces 'within' an aggregate
* object. But, using an additional interface only allows returning one
* underlying JSObject. However, this allows for the possibility that
* each of the aggregte JSObjects could return something different.
* Note that one might do: this.wrappedJSObject = someOtherObject;
* iii) Avoiding the explicit interface makes it easier for both the caller
* and the component.
*
* Anyway, some future implementation of nsIXPCSecurityManager might want
* do special processing on 'nsIXPCSecurityManager::CanGetProperty' when
* the interface id is that of nsIXPCWrappedJSObjectGetter.
*/
[scriptable, uuid(254bb2e0-6439-11d4-8fe0-0010a4e73d9a)]
interface nsIXPCWrappedJSObjectGetter : nsISupports
{
readonly attribute nsISupports neverCalled;
};
/***************************************************************************/
%{ C++
// For use with the service manager
// {CB6593E0-F9B2-11d2-BDD6-000064657374}
#define NS_XPCONNECT_CID \
{ 0xcb6593e0, 0xf9b2, 0x11d2, \
{ 0xbd, 0xd6, 0x0, 0x0, 0x64, 0x65, 0x73, 0x74 } }
%}
[noscript, uuid(768507b5-b981-40c7-8276-f6a1da502a24)]
interface nsIXPConnect : nsISupports
{
%{ C++
NS_DEFINE_STATIC_CID_ACCESSOR(NS_XPCONNECT_CID)
%}
/**
* wrapNative will create a new JSObject or return an existing one.
*
* This method now correctly deals with cases where the passed in xpcom
* object already has an associated JSObject for the cases:
* 1) The xpcom object has already been wrapped for use in the same scope
* as an nsIXPConnectWrappedNative.
* 2) The xpcom object is in fact a nsIXPConnectWrappedJS and thus already
* has an underlying JSObject.
*
* It *might* be possible to QueryInterface the nsIXPConnectJSObjectHolder
* returned by the method into a nsIXPConnectWrappedNative or a
* nsIXPConnectWrappedJS.
*
* This method will never wrap the JSObject involved in an
* XPCNativeWrapper before returning.
*
* Returns:
* success:
* NS_OK
* failure:
* NS_ERROR_XPC_BAD_CONVERT_NATIVE
* NS_ERROR_XPC_CANT_GET_JSOBJECT_OF_DOM_OBJECT
* NS_ERROR_FAILURE
*/
JSObjectPtr
wrapNative(in JSContextPtr aJSContext,
in JSObjectPtr aScope,
in nsISupports aCOMObj,
in nsIIDRef aIID);
/**
* Same as wrapNative, but it returns the JSObject in aVal. C++ callers
* must ensure that aVal is rooted.
* aIID may be null, it means the same as passing in
* &NS_GET_IID(nsISupports) but when passing in null certain shortcuts
* can be taken because we know without comparing IIDs that the caller is
* asking for an nsISupports wrapper.
* If aAllowWrapper, then the returned value will be wrapped in the proper
* type of security wrapper on top of the XPCWrappedNative (if needed).
* This method doesn't push aJSContext on the context stack, so the caller
* is required to push it if the top of the context stack is not equal to
* aJSContext.
*/
void
wrapNativeToJSVal(in JSContextPtr aJSContext,
in JSObjectPtr aScope,
in nsISupports aCOMObj,
in nsWrapperCachePtr aCache,
in nsIIDPtr aIID,
in boolean aAllowWrapper,
out jsval aVal);
/**
* wrapJS will yield a new or previously existing xpcom interface pointer
* to represent the JSObject passed in.
*
* This method now correctly deals with cases where the passed in JSObject
* already has an associated xpcom interface for the cases:
* 1) The JSObject has already been wrapped as a nsIXPConnectWrappedJS.
* 2) The JSObject is in fact a nsIXPConnectWrappedNative and thus already
* has an underlying xpcom object.
* 3) The JSObject is of a jsclass which supports getting the nsISupports
* from the JSObject directly. This is used for idlc style objects
* (e.g. DOM objects).
*
* It *might* be possible to QueryInterface the resulting interface pointer
* to nsIXPConnectWrappedJS.
*
* Returns:
* success:
* NS_OK
* failure:
* NS_ERROR_XPC_BAD_CONVERT_JS
* NS_ERROR_FAILURE
*/
void
wrapJS(in JSContextPtr aJSContext,
in JSObjectPtr aJSObj,
in nsIIDRef aIID,
[iid_is(aIID),retval] out nsQIResult result);
/**
* Wraps the given jsval in a nsIVariant and returns the new variant.
*/
nsIVariant
jSValToVariant(in JSContextPtr cx, in jsval aJSVal);
/**
* This only succeeds if the JSObject is a nsIXPConnectWrappedNative.
* A new wrapper is *never* constructed.
*/
nsIXPConnectWrappedNative
getWrappedNativeOfJSObject(in JSContextPtr aJSContext,
in JSObjectPtr aJSObj);
void debugDump(in short depth);
void debugDumpObject(in nsISupports aCOMObj, in short depth);
void debugDumpJSStack(in boolean showArgs,
in boolean showLocals,
in boolean showThisProps);
/**
* wrapJSAggregatedToNative is just like wrapJS except it is used in cases
* where the JSObject is also aggregated to some native xpcom Object.
* At present XBL is the only system that might want to do this.
*
* XXX write more!
*
* Returns:
* success:
* NS_OK
* failure:
* NS_ERROR_XPC_BAD_CONVERT_JS
* NS_ERROR_FAILURE
*/
void
wrapJSAggregatedToNative(in nsISupports aOuter,
in JSContextPtr aJSContext,
in JSObjectPtr aJSObj,
in nsIIDRef aIID,
[iid_is(aIID),retval] out nsQIResult result);
// Methods added since mozilla 0.6....
JSObjectPtr
getWrappedNativePrototype(in JSContextPtr aJSContext,
in JSObjectPtr aScope,
in nsIClassInfo aClassInfo);
jsval variantToJS(in JSContextPtr ctx, in JSObjectPtr scope, in nsIVariant value);
nsIVariant JSToVariant(in JSContextPtr ctx, in jsval value);
/**
* Create a sandbox for evaluating code in isolation using
* evalInSandboxObject().
*
* @param cx A context to use when creating the sandbox object.
* @param principal The principal (or NULL to use the null principal)
* to use when evaluating code in this sandbox.
*/
[noscript] JSObjectPtr createSandbox(in JSContextPtr cx, in nsIPrincipal principal);
/**
* Evaluate script in a sandbox, completely isolated from all
* other running scripts.
*
* @param source The source of the script to evaluate.
* @param filename The filename of the script. May be null.
* @param cx The context to use when setting up the evaluation of
* the script. The actual evaluation will happen on a new
* temporary context.
* @param sandbox The sandbox object to evaluate the script in.
* @return The result of the evaluation as a jsval. If the caller
* intends to use the return value from this call the caller
* is responsible for rooting the jsval before making a call
* to this method.
*/
[noscript] jsval evalInSandboxObject(in AString source, in string filename,
in JSContextPtr cx,
in JSObjectPtr sandbox);
[noscript] void writeScript(in nsIObjectOutputStream aStream,
in JSContextPtr aJSContext,
in JSScriptPtr aJSScript);
[noscript] JSScriptPtr readScript(in nsIObjectInputStream aStream,
in JSContextPtr aJSContext);
[noscript] void writeFunction(in nsIObjectOutputStream aStream,
in JSContextPtr aJSContext,
in JSObjectPtr aJSObject);
[noscript] JSObjectPtr readFunction(in nsIObjectInputStream aStream,
in JSContextPtr aJSContext);
};