Closed
Bug 572953
Opened 14 years ago
Closed 14 years ago
Cu.evalInSandbox should not ignore wrappedJSObject
Categories
(Core :: XPConnect, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta7+ |
People
(Reporter: ddahl, Assigned: peterv)
References
Details
in a snippet like this:
this.sandbox = new Cu.Sandbox(this._window);
this.sandbox.window = this._window;
this.sandbox.__proto__ = this._window.wrappedJSObject;
when running:
Cu.evalInSandbox(str, this.sandbox);
The wrappedJSObject is ignored.
Reporter | ||
Updated•14 years ago
|
Assignee: general → mrbkap
Comment 1•14 years ago
|
||
Ignored in what sense?
Comment 2•14 years ago
|
||
As part of bug 386635, content sandbox objects are returned in SJOWs. SJOWs wrap objects across boundaries, so if GreaseMonkey did:
sandbox.__proto__ = new XPCNativeWrapper(contentWindow);
sandbox's proto would end up being a XOW around the content window instead of the intended XPCNW. In order to fix that, I detect that case and "fix" it. Unfortunately, if you're not GreaseMonkey, it has very unexpected behavior. We need to come up with a clean way of setting up a sandbox whose wrapping behavior is well-defined.
Component: JavaScript Engine → XPConnect
QA Contact: general → xpconnect
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 3•14 years ago
|
||
TODO: When this bug is fixed, remove the workaround introduced in bug 574033.
Comment 4•14 years ago
|
||
Doesn't sound like something that must be fixed for Firefox 4.
blocking2.0: ? → -
Reporter | ||
Comment 5•14 years ago
|
||
we do have a work around, so unless further testing shows otherwise we can do without. Our workaround is a bit hacky, perhaps someone can take a peek at bug 574033 and let us know if we are being insecure?
Updated•14 years ago
|
Assignee: mrbkap → peterv
blocking2.0: - → ?
Comment 6•14 years ago
|
||
Is this still relevant after the compartments landing, with the evalInSandbox API changes etc?
Reporter | ||
Comment 8•14 years ago
|
||
We just have to test with the new API. Our current code looks like:
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/console/hudservice/HUDService.jsm?force=1#4142
4142 createSandbox: function JST_setupSandbox()
4143 {
4144 // create a JS Sandbox out of this.context
4145 this.sandbox = new Cu.Sandbox(this._window);
4146 this.sandbox.window = this._window;
4147 this.sandbox.console = this.console;
4148 this.sandbox.__helperFunctions__ = JSTermHelper(this);
4149 this.sandbox.__proto__ = this._window.wrappedJSObject;
4150 },
I think mrbkap said to do it like this instead:
this.sandbox = new Cu.Sandbox(this._window, this._window, false);
this.sandbox.window = this._window;
this.sandbox.console = this.console;
Is that right?
Comment 10•14 years ago
|
||
Though this was actually fixed by peterv's changes in bug 604957 and the changes to make the webconsole use the correct sandbox constructor.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•