Closed
Bug 664689
Opened 13 years ago
Closed 13 years ago
getOwnPropertyDescriptor does not work for content objects when invoked from chrome code
Categories
(Core :: XPConnect, defect)
Tracking
()
RESOLVED
FIXED
mozilla8
People
(Reporter: past, Assigned: mrbkap)
Details
(Whiteboard: fixed-in-tracemonkey)
Attachments
(1 file)
4.02 KB,
patch
|
gal
:
review+
|
Details | Diff | Splinter Review |
In bug 651501 we ran across a weird problem with getOwnPropertyDescriptor. Object.getOwnPropertyDescriptor(o,p) does not work the same when checking content- vs. chrome-provided objects. The web console runs with chrome privileges and I had to resort to using scope.Object.getOwnPropertyDescriptor(o,p), where scope is the global for o, to have it work for content. Is this expected behavior or is it a bug? Bug 607284 seems somewhat related.
Reporter | ||
Updated•13 years ago
|
Summary: getOwnPropertyDescriptor → getOwnPropertyDescriptor does not work for content objects when invoked from chrome code
Comment 1•13 years ago
|
||
Per bug 664426, it seems like the actual issue here is what getOwnPropertyDescriptor should do on our security-wrapper proxies, right? Is this an issue for all properties (and an issue for the safe object wrapper), or just an issue for XPConnect stuff on XrayWrapper?
Reporter | ||
Comment 2•13 years ago
|
||
(In reply to comment #1) > Per bug 664426, it seems like the actual issue here is what > getOwnPropertyDescriptor should do on our security-wrapper proxies, right? Presumably, yes, although I'm not familiar with the implementation of getOwnPropertyDescriptor. > Is this an issue for all properties (and an issue for the safe object > wrapper), or just an issue for XPConnect stuff on XrayWrapper? I'm not sure I understand the distinction, so I'll describe how the problem manifests itself instead. I have a web page with the following object defined: var OBJ = { get foo() { alert(1); delete OBJ.foo; return "bar"; } } I type the following into Scratchpad with the content as execution environment: console.log(Object.getOwnPropertyDescriptor(OBJ, "foo").toSource()); It prints the property descriptor as expected. I then type the following into Scratchpad with the browser as execution environment: var wrappedWin = gBrowser.selectedBrowser.contentWindow; var win = XPCNativeWrapper.unwrap(wrappedWin); var obj = win.OBJ; win.console.log(win.Object.getOwnPropertyDescriptor(obj, "foo").toSource()); win.console.log(Object.getOwnPropertyDescriptor(obj, "foo")); The first console.log line prints the object descriptor as expected, while the second prints undefined. This bug is about the latter case. Substituting document.__proto__ for OBJ and "body" for "foo", works in content, but throws in browser context. This latter issue is bug 560072.
Comment 3•13 years ago
|
||
> I'm not sure I understand the distinction
I'd be happy to explain (catch me on irc), but given your example you're talking about the safe object wrappper.
Assignee | ||
Comment 4•13 years ago
|
||
The problem here is that the CrossOriginWrapper (we really need a better name) is actually a double wrapper. So the simplistic desc->obj == obj check gets confused because we find the property on the real underlying object. By using JSProxy::getOwnPropertyDescriptor, we don't have to guess anymore as to whether or not we found the property on the right object.
Comment 5•13 years ago
|
||
Comment on attachment 541549 [details] [diff] [review] Proposed fix Nice test.
Attachment #541549 -
Flags: review?(gal) → review+
Assignee | ||
Comment 6•13 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/8565b7114e6f
Whiteboard: fixed-in-tracemonkey
Comment 7•13 years ago
|
||
cdleary-bot mozilla-central merge info: http://hg.mozilla.org/mozilla-central/rev/8565b7114e6f
Updated•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
You need to log in
before you can comment on or make changes to this bug.
Description
•