archives

« Bugzilla Issues Index

#1459 — 15.2.4.2: Censor "Object" again (revert bug 1148)


The algorithm for Object.prototype.toString has substantially changed in rev14 from the version in rev12, which may make it necessary to censor "Object" again. That means reverting the solution from bug 1148.

Specifically it's currently possible to masquerade non-Objects as Objects:
> js> a = [], a[getSym("@@toStringTag")] = "Object"
> "Object"
> js> Object.prototype.toString.call(a)
> "[object Object]"
> js> f = ()=>{}, f[getSym("@@toStringTag")] = "Object"
> "Object"
> js> Object.prototype.toString.call(f)
> "[object Object]"


Why is this a problem. "Object" should also be available as a toStringTag. I don't seen any problem at all in somebody, for example, subclassing Array (which by default will give them exotic array instance objects) and then using @@toStringTag to cause toString to report [object Object] instead of [object Array].

We're only support identify the ES5 built-in exotics (plus symbols) to keep legacy code working. As soon as you start using @@toStringTag it isn't pre-ES6 legacy code anymore.


I don't see how this matches the note in 15.2.4.2:
> The above definition of toString preserves the ability to use it
> as a reliable test for those specific kinds of built-in objects [...]


(In reply to comment #2)
> I don't see how this matches the note in 15.2.4.2:
> > The above definition of toString preserves the ability to use it
> > as a reliable test for those specific kinds of built-in objects [...]

Well, I wrote the text of that note so perhaps I could have be made clearer that it is talking about compatibility with legacy code. That is one of the implications of the "but" clause of the final sentence.

There was no real "subclassing" of Array (or other built-ins) prior to ES6 so we don't have to worry about compatibility with legacy subclassing of them.

Can you think of any valid ES5 code that would break because of how this is currently spec'ed?


Although custom @@toString hooks will most likely used for sub-classing, this particular problem is not restricted to sub-classing. I've just wanted to raise this bug report to make sure the behavioral change from rev13 to rev14 was intentional.


fixed in rev26 editor's draft

toString has evlolved since this bug was filed, but the basic issue remains. Elaborated the note to clarify that @@toStringTag could be used to invalidate the legacy compatibility of type testing using toString.


fixed in rev26