Edited to remove noise: <mrbkap> [...] I think I talked about this with brendan a while ago and we decided that MirrorWrappedNativeParent was rampant over-paranoia. <brendan> yup, from 2005 iirc <mrbkap> jorendorff: The question is: what parent should chrome XPCNativeWrappers have? <jorendorff> mrbkap: good question! and i think the answer is, they should just be parented to whatever chrome scope asks for them first <jorendorff> mrbkap: it's arbitrary, but <jorendorff> for compartments it's got to be chrome <mrbkap> Yeah. <jorendorff> and better an arbitrary right answer than a specific wrong one <mrbkap> Right, ok.

That doesn't seem to work if the chrome scope that asked for them first goes away, does it? Perhaps we always need an SJOW around XPCNW?

The parent link is a strong reference, so this would keep the scope alive. I can imagine an objection to this on the grounds that it would entrain garbage, but that's the sort of thing we can maybe live with -- would it be likely to happen in practice? Long-term, I think we should make the parent chain go away for objects like this where it really doesn't matter except as a peg to hang security principals on. Compartments can be that peg instead, once we have them. Then there will be no parent chain to entrain garbage...

Shorter term, we could create fake "scope" objects for each compartment. So we'd create an object that when asked by caps, would return "system", but we'd never actually run any code against it. Right now all wrappers have a null proto, so I don't even think that we'd need to make it a global object as in JSCLASS_GLOBAL_FLAGS.

Andreas reimplemented all the wrappers on top of proxies. In the new implementation, XPCNW is called XrayWrapper<JSCrossCompartmentWrapper> and all wrappers are parented to whatever global is currently on the scope chain-- it behaves like what I suggested on IRC in comment 0. This will turn itself on automatically when Gecko gets compartmentalized, so there's no point changing XPCNW.