On 12/3/12 11:14 PM, Bobby Holley wrote:
The problem happens when people try to find and access said reflection, usually by way of the wrapper cache.
The problem comes when one has to work with a JS gcthing of any sort. That includes strings, but yes also objects.
A related problem is that people are creating typed arrays with the cx compartment, stashing them (and presumably CCing them) on the C++ object, and (later) expecting them to be same-compartment with the object in the wrapper cache.
And similar for callback functions. And WebIDL "any" values (for now reflected as JS::Value; we should revisit that). Basically, pretty much any time JSAPI leaks through to content code you start having to worry about whether all your ducks are in the same compartment.
But it's still not the common case.
It's the common case in nearly all the new code we're adding, as far as I can tell. :(
The problem is that C++ code is assuming that the compartments of GetCurrentJSContext() and xpcomObj->GetWrapper() are guaranteed to be same-compartment, when they're not.
I'd go further: the problem is that C++ code has to hold on to JS objects for various reasons, and then it has to worry about whether those objects are in the same compartment. And it doesn't help that some operations (adoptNode, hey) replaces some of the objects, but not all, with objects from a different compartment...
Note that at this point, given the above, I think it's not feasible to avoid compartment checks in binding code and elsewhere in the DOM. The best I'm hoping for now is that we make them fast... Having an inline API for getting the compartment of a JSContext would be nice, for example.
-Boris _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
