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
•