According to sections B.3.1<http://people.mozilla.org/~jorendorff/es6-draft.html#sec-B.3.1>#6.a and 16.1.1.1.2<http://people.mozilla.org/~jorendorff/es6-draft.html#sec-16.1.1.1.2>#3, implementations are expected to throw a TypeError exception if an object's __proto__ is set with anything other than null or an object. Today the existing implementations (Chrome or Firefox) treat such assignments as a no op.

Interestingly there are instances of web pages who assign undefined to an objects __proto__ are found. For example yelp.com<http://www.yelp.com/biz/potbelly-sandwich-shop-seattle-4> assigns undefined to __proto__ via a function call as follows.

function(f) { return { __proto__:f } }

Implementing as per the specification would break the zoom in/out functionality of Yelp as this function would throw a TypeError. Similarly a radio player on myspace.com<http://myspace.com/> would not work either.  The fact that there are few instances we have seen in the wild would mean there could be more websites that could break.

Is the v8/spidermonkey behavior of silently ignoring primitive assignments to __proto__ a bug? Or should the spec mandate silently ignoring assignments of primitives (or just undefined) to __proto__?

- Suresh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130822/613b939f/attachment.html>

According to sections [B.3.1](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-B.3.1)#6.a and [16.1.1.1.2](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-16.1.1.1.2)#3, implementations are expected to throw a `TypeError` exception if an object's `__proto__` is set with anything other than `null` or an object. Today the existing implementations (Chrome or Firefox) treat such assignments as a no op.

Interestingly there are instances of web pages who assign undefined to an objects `__proto__` are found. For example [yelp.com](http://www.yelp.com/biz/potbelly-sandwich-shop-seattle-4) assigns undefined to `__proto__` via a function call as follows.

```js
function(f) { return { __proto__:f } }
```

Implementing as per the specification would break the zoom in/out functionality of Yelp as this function would throw a `TypeError`. Similarly a radio player on [myspace.com](http://myspace.com/) would not work either.  The fact that there are few instances we have seen in the wild would mean there could be more websites that could break.

Is the v8/spidermonkey behavior of silently ignoring primitive assignments to `__proto__` a bug? Or should the spec mandate silently ignoring assignments of primitives (or just undefined) to `__proto__`?