getOwnPropertyDescriptor does not work for content objects when invoked from chrome code

RESOLVED FIXED in mozilla8

Status

()

RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: past, Assigned: mrbkap)

Tracking

Trunk
mozilla8
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment)

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.
Summary: getOwnPropertyDescriptor → getOwnPropertyDescriptor does not work for content objects when invoked from chrome code
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?
(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.
> 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.
Created attachment 541549 [details] [diff] [review]
Proposed fix

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.
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #541549 - Flags: review?(gal)

Comment 5

7 years ago
Comment on attachment 541549 [details] [diff] [review]
Proposed fix

Nice test.
Attachment #541549 - Flags: review?(gal) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
You need to log in before you can comment on or make changes to this bug.