Closed Bug 785822 Opened 7 years ago Closed 7 years ago

throws "Illegal operation on WrappedNative prototype object" while trying to access the property of prototype when Window is used as a proto for some random object.

Categories

(Core :: XPConnect, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: badkaikai, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1

Steps to reproduce:

var bug = {};
bug.__proto__ = window;
try {
    bug['name']
} catch(e) {
    console.log(e.message);
}

Illegal operation on WrappedNative prototype object


Actual results:

It throws `Illegal operation on WrappedNative prototype object`.


Expected results:

should return window['name'].
Component: Untriaged → XPConnect
Product: Firefox → Core
M-C
Cannot reproduce:
http://hg.mozilla.org/mozilla-central/rev/4b9608fd670c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120207 Firefox/13.0a1 ID:20120207224449
Reproduced:
http://hg.mozilla.org/mozilla-central/rev/06b063c001b6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120208 Firefox/13.0a1 ID:20120208042354
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4b9608fd670c&tochange=06b063c001b6

M-I
Cannot reproduce:
http://hg.mozilla.org/integration/mozilla-inbound/rev/3e7875d6ee51
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120207 Firefox/13.0a1 ID:20120207172449
Reproduced:
http://hg.mozilla.org/integration/mozilla-inbound/rev/bc6a70cdc0e7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120207 Firefox/13.0a1 ID:20120207190551
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3e7875d6ee51&tochange=bc6a70cdc0e7
Blocks: 622301
Yep, this was a purposeful change in bug 622301.

That said, switching Window to WebIDL bindings will change behavior here for things that rely on the GSP like comment 0 does to work again, possibly.  Certainly this works fine:

  <script name="foo">
  var bug = {};
  bug.__proto__ = document.getElementsByTagName("script");
  try {
      alert(bug['foo'])
  } catch(e) {
      console.log(e.message);
  }
  </script>

though I can't tell whether that's correct or not per spec at the moment.
Cameron, what _is_ the per-spec-correct behavior here for named getter stuff?
I believe the comment 3 code should alert the script element, because:

* We call [[Get]]("foo") on bug
* http://people.mozilla.org/~jorendorff/es5.html#sec-8.12.3 in step 1 calls
  [[GetProperty]]("foo") on bug
* In http://people.mozilla.org/~jorendorff/es5.html#sec-8.12.2 prop will be undefined
  since bug doesn't have an own property named "foo", so we call
  [[GetProperty]]("foo") on the HTMLCollection in step 5
* In this call to http://people.mozilla.org/~jorendorff/es5.html#sec-8.12.2 well
  call [[GetOwnProperty]]("foo") on the HTMLCollection in step 1
* We get in to step 3 in http://dev.w3.org/2006/webapi/WebIDL/#getownproperty
  and return the HTMLScriptElement object.
Bobby, would it make sense to for now walk up the proto chain in PRE_HELPER_STUB looking for the right thing?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: throws "Illegal operation on WrappedNative prototype object" while trying to access the property of prototype. → throws "Illegal operation on WrappedNative prototype object" while trying to access the property of prototype when Window is used as a proto for some random object.
(In reply to Boris Zbarsky (:bz) from comment #6)
> Bobby, would it make sense to for now walk up the proto chain in
> PRE_HELPER_STUB looking for the right thing?

I don't fully grok the distinction of when we want to walk up the proto chain for DOM objects and when we don't. Are you saying we want to do it only for named property getters? If so, it seems like doing it in the scriptable helper code is a pretty coarse way of going about it, and will cause it to work for other random things too (document.location, anyone?).
> Are you saying we want to do it only for named property getters?

Per spec, yes.

> If so, it seems like doing it in the scriptable helper code is a pretty coarse way of
> going about it

Well, the scriptable helper code is what throws right now, so lower-level code never gets a chance to do anything with it.

Yes, it will change the behavior of some things.  This is all temporary until we move fully to WebIDL bindings.
Wait.  This bug is specifically about getting the "name" property, not about some random name.  That property is defined in WebIDL, and for that specific property throwing is in fact the right behavior.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.