Last Comment Bug 565730 - Parent XPCNativeWrappers to chrome
: Parent XPCNativeWrappers to chrome
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: Other Branch
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks: 563106
  Show dependency treegraph
 
Reported: 2010-05-13 12:44 PDT by Jason Orendorff [:jorendorff]
Modified: 2010-07-16 08:13 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jason Orendorff [:jorendorff] 2010-05-13 12:44:02 PDT
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.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2010-05-13 12:55:14 PDT
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?
Comment 2 Jason Orendorff [:jorendorff] 2010-05-13 14:37:57 PDT
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...
Comment 3 Blake Kaplan (:mrbkap) 2010-05-13 19:57:55 PDT
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.
Comment 4 Jason Orendorff [:jorendorff] 2010-07-16 08:13:57 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.