It was inevitable. Tom Austin is working on an Fx addon to mess with JSAPI from within script. This is perfectly doable with ctypes (ignoring the giant footgun waving in one's face); we just need a few basic accessors. For starters: 1) Get the JSContext* of the currently executing script. 2) Get a JSObject*/JSString*/jsval from a script object, and vice versa. 3) Expose whatever other various constants and macros are useful. There are two ways we could accomplish this. a) Hang everything off a 'ctypes.jsapi' object that's implemented in jsengine (i.e. within ctypes itself). b) Add a 'jsapi.jsm' in toolkit/components, which gives you a 'jsapi' on the global, and implement everything there. Doing the former is easy, but it means the implementation lives in jsengine and is thus available to all ctypes users. (We could add a separate JS_InitJSAPIOnCTypes(JSContext* cx, JSObject* ctypes) API so you don't get it by default, if desired.) The latter gets it just for toolkit apps, and means we need to add JSAPI functions to create CTypes and CDatas. (Which is something we want to do anyway, precisely so that embeddors can play with it.) Which would the jsengine folks prefer?

This gives you a 'ctypes.cx()' method which returns a CData PointerType. (To declare JSAPI functions taking a JSContext*, use ctypes.cx().constructor, which is built from a ctypes.StructType("JSContext").ptr.) This patch is for testing only.

> We could add a separate JS_InitJSAPIOnCTypes(JSContext* cx, JSObject* ctypes Good idea. My suggestion is to implement in js/src/ctypes but don't install the low-level JS API reflection by default. I'm scared enough with native types and pointers! /be

Reassigning to nobody. If anyone wants to work on this, feel free!

As noted in the similar bug 717886, I am opposed to the premise of this bug because of the giant footgun opportunity here. If you really want JSAPI, binaries are a better option.