On Wed, Apr 17, 2013 at 5:21 AM, Matthew Gertner <matt...@salsitasoft.com>wrote:
> I'm using Cu.evalInSandbox in a bootstrapped extension to run code in an
> isolated environment using a content window as the sandbox prototype. When
> the code adds expando properties to the window (e.g. jQuery), the sandbox
> predictably leaks when the extension is disabled.
>
This is because Xray expandos are actually stored in the scope of the
target object (we do this so that they can be shared by multiple
same-origin Xraying compartments). So if you do:
contentWindowXrayWrapper.foopy = {},
You'll wind up creating a backreference from the content scope into your
sandbox, which will hold your sandbox alive as long as the content DOM
window is alive. Note that this doesn't happen if you assign a primitive
(like |42|) to foopy.
I assume that the sandbox gets an Xray wrapper for the window that is
> specially created for it. What is the best way to remove all expando
> properties added in the sandbox or otherwise destroy this wrapper when the
> extension is disabled?
When you want the sandbox to die, you can do
|Components.utils.nukeSandbox(sandbox)|, and it'll go away. Simple as that.
:-)
The best idea I'm having is to set wantXrays to false when creating the
> sandbox and pass in my own wrapper using Object.create(window). That way I
> can iterate over the wrapper when I want to free the sandbox and null out
> any own properties.
>
That is indeed clever, but has the potential to break a lot of the special
handling we do to make |this|-bindings work properly in conjunction with
sandboxPrototype. This stuff already pushes the boundaries a little bit, so
I'd shy away of clever tricks like that lest they end up being broken down
the line.
Cheers,
bholley
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
