On Wednesday, April 17, 2013 3:57:58 PM UTC+2, Bobby Holley wrote:
When you want the sandbox to die, you can do
|Components.utils.nukeSandbox(sandbox)|, and it'll go away. Simple as that.
:-)
I've been using this, and it indeed nukes the sandbox even if there are
backreferences from expando
On 4/22/13 4:37 AM, Matthew Gertner wrote:
However, the sandbox lives on if it contains DOM event handlers that have not
been removed.
Event handlers, or event listeners?
For event listeners, this happens because they're not holding
cross-compartment wrappers, presumably... and that's not
I've filed bug 864313 for improving the situation here. Should be pretty
straightforward to do.
On Mon, Apr 22, 2013 at 9:20 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/22/13 4:37 AM, Matthew Gertner wrote:
However, the sandbox lives on if it contains DOM event handlers that have
not
Boris - sorry, these are event listeners.
Bobby - that would rock. I'm removing the event listeners manually but this
requires some hardcoded dependencies to jQuery that I'd love to get rid of.
___
dev-platform mailing list
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.
I assume that the
On Wed, Apr 17, 2013 at 5:21 AM, Matthew Gertner matt...@salsitasoft.comwrote:
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
On Wednesday, April 17, 2013 3:57:58 PM UTC+2, Bobby Holley wrote:
When you want the sandbox to die, you can do
|Components.utils.nukeSandbox(sandbox)|, and it'll go away. Simple as that.
:-)
Awesome, exactly what I was looking for! I'm not sure how I missed that (would
be good to reference
7 matches
Mail list logo
