JS_NewGlobalObject

This article covers features introduced in SpiderMonkey 17

Create a new JavaScript object for use as a global object.

Syntax

JSObject *
JS_NewGlobalObject(JSContext *cx, const JSClass *clasp, JSPrincipals *principals,
                   JS::OnNewGlobalHookOption hookOption,
                   const JS::CompartmentOptions &options = JS::CompartmentOptions());
Name Type Description
cx JSContext * The context in which to create the new global object. Requires request. In a JS_THREADSAFE build, the caller must be in a request on this JSContext.
clasp Jsclass *

The class to use for the new global object.

clasp->flags must have the JSCLASS_GLOBAL_FLAGS bits set.

The caller must ensure that the JSClass remains alive throughout the lifetime of the new object, including the garbage collection cycle that finally frees it. The usual way to do this is to make JSClasses global or static.
principals JSPrincipals * The security information to associate with this compartment.
hookOption JS::OnNewGlobalHookOption See Debugger API Hook Added in SpiderMonkey 31
options const JS::CompartmentOptions & The option for new compartment (passed to JScompartment constructor). Added in SpiderMonkey 31

Description

JS_NewGlobalObject creates a new global object based on the specified class.

The new object has no parent. It initially has no prototype either, since it is typically the first object created; call JS_InitStandardClasses to create all the standard objects, including Object.prototype, and set the global object's prototype.

The constructor clasp->construct is not called.

On success, JS_NewGlobalObject returns a pointer to the new object. Otherwise it returns NULL.

Debugger API Hook

During global creation, we fire notifications to callbacks registered via the Debugger API. These callbacks are arbitrary script, and can touch the global in arbitrary ways. When that happens, the global should not be in a half-baked state. But this creates a problem for consumers that need to set slots on the global to put it in a consistent state.

This API provides a way for consumers to set slots atomically (immediately after the global is created), before any debugger hooks are fired. It's unfortunately on the clunky side, but that's the way the cookie crumbles.

If callers have no additional state on the global to set up, they may pass FireOnNewGlobalHook to JS_NewGlobalObject, which causes that function to fire the hook as its final act before returning. Otherwise, callers should pass DontFireOnNewGlobalHook, which means that they are responsible for invoking JS_FireOnNewGlobalObject upon successfully creating the global. If an error occurs and the operation aborts, callers should skip firing the hook. But otherwise, callers must take care to fire the hook exactly once before compiling any script in the global's scope (we have assertions in place to enforce this). This lets us be sure that debugger clients never miss breakpoints.

enum OnNewGlobalHookOption {
    FireOnNewGlobalHook,
    DontFireOnNewGlobalHook
};

See Also