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.
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 JSClass es 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
- MXR ID Search for
JS_NewGlobalObject
- MXR ID Search for
OnNewGlobalHookOption
- bug 897322
- bug 880917
- bug 759585
- bug 570040
- bug 755186
- bug 1239666 - options is no longer optional