Discuss
  • __proto__ : Spec & web compatibility

__proto__ : Spec & web compatibility

# Suresh Jayabalan (12 years ago)

According to sections B.3.1#6.a and 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 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 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__?

# Brendan Eich (12 years ago)

I implemented __proto__ ages ago and it caught on like a non-lethal social disease, and that's how it works. The way it works ought to be how Annex B specifies it.

# J B (12 years ago)

I recently wrote a AS3 to JS transcompiler that relies quite heavily on __proto__. The outputted JS works perfectly in both Chrome (SVG SUPPORT IS HORRIBLE, sorry, unrelated) and Firefox, and maybe even IE11 --I need to verify. Anyway, for projects like mine, it's very important that IE matches the same functionality as the other browsers --even if it's not up to spec.

Also, if it wasn't for __proto__, I don't think I could have supported the entire AS3 spec... so, no hating on __proto__ =)

# Andreas Rossberg (12 years ago)

On 22 August 2013 02:44, Brendan Eich <brendan at mozilla.com> wrote:

I implemented __proto__ ages ago and it caught on like a non-lethal social disease, and that's how it works. The way it works ought to be how Annex B specifies it.

It has occasionally been quite lethal to a number of web pages that carelessly used plain objects as maps. :=P

# Brendan Eich (12 years ago)

Just a flesh wound :-P.

Do bugs of this dictionary kind (real user input including __proto__ is an attack, and no joke, I agree) change the argument about non-object RHS? My point is we're still alive (somehow) and stuck with annex B specification.