Re: Number.prototype not being an instance breaks the web, too
Please note that the `@@toStringTag` changes mean that we do need to always
have a Number.prototype method that throws when the value does not have
a [[NumberData]] internal slot - I'm using `Number#toString` for that right
now, but others may now be relying on the throw behavior of `Number#valueOf.
On Mon, Apr 13, 2015 at 8:50 AM, Mathias Bynens math...@qiwi.be wrote:
CCing Piotr.
On Mon, Apr 13, 2015 at 5:37 PM, Mark S. Miller erig...@google.com
wrote:
Hold on. I may have reacted too quickly. If it is only jsfiddle, since
this
is an online service rather than a widely copied library, they could just
fix it. OTOH, if it really is a mootools issue, then yes, we really do
need
to change the spec. (History: Facebook fixed JSON incompatibility. ES5
fixed
Object.prototype.toString.call(null) incompat with jQuery.)
Could someone please reply-all to this thread cc'ing Piotr Zalewa and
Oskar
Krawczyk? Thanks.
On Mon, Apr 13, 2015 at 8:26 AM, Mark S. Miller erig...@google.com
wrote:
I agree. With Number.prototype joining Array.prototype and
Function.prototype on the dark side, we should ask which others should
too.
When it was only Function.prototype and Array.prototype, principle of
least
surprise (POLS) had us keep the list as small as possible -- until we
had
precisely this kind of evidence of incompatibility. From a security
pov, the
important ones not to revert are those carrying mutable state not locked
down by Object.freeze. In ES5 this was only Date.prototype. Of the ES5
builtins in ES6, this now includes RegExp.prototype because of
RegExp.prototype.compile. (Because of de facto stack magic, this might
include Error.prototype as well.) Fotunately, there is still no evidence
that we need to corrupt these as well.
OTOH, POLS still says that almost everything should not go to the dark
side, for consistency with ES6 classes. So the precise line becomes a
matter
of taste. I propose that the co-corrupted list be
Function.prototype
Array.prototype
Number.prototype
Boolean.prototype // No incompat data. Only POLS
String.prototype // No incompat data. Only POLS
since Number, Boolean, and String are the ordinary ES5 wrappers of
primitive data values.
For builtins that are new with ES6, clearly there's no compat issue. And
both security and consistency with ES6 classes argue in general for not
corrupting new things. But POLS should put very little weight on the
ES5 vs
ES6 difference since post ES6 programmers will just see all of this as
JS.
Given that, I could argue Symbol.prototype either way, since Symbol is
kinda another wrapper of a primitive type. But I prefer not. I think we
should keep the list to those 5.
Allen, process-wise, is this too late for ES6? If there's any way this
fix
can go in ES6, it should. Otherwise, it should become the first member
of
ES6 errata.
All that said, I do find corrupting only Number.prototype to be
plausible.
I would not mind if we decided not to spread the corruption even to
Boolean.prototype and String.prototype. If we have to do a last minute
as-small-as-possible change to the spec, to get it into ES6, this might
be
best.
On Mon, Apr 13, 2015 at 7:47 AM, Andreas Rossberg rossb...@google.com
wrote:
V8 just rolled a change into Canary yesterday that implements the new
ES6
semantics for Number.prototype (and Boolean.prototype) being ordinary
objects. Unfortunately, that seems to break the web. In particular
http://jsfiddle.net/#run fails to load now.
What I see happening on that page is a TypeError
Number.prototype.valueOf is not generic being thrown in this function
(probably part of moo tools):
Number.prototype.$family = function(){
return isFinite(this) ? 'number' : 'null';
}.hide();
after being invoked on Number.prototype.
AFAICS, that leaves only one option: backing out of this spec change.
(See https://code.google.com/p/chromium/issues/detail?id=476437 for
the
bug.)
/Andreas
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.prototype not being an instance breaks the web, too
On Mon, Apr 13, 2015 at 12:53 PM, Jordan Harband ljh...@gmail.com wrote: Please note that the `@@toStringTag` changes mean that we do need to always have a Number.prototype method that throws when the value does not have a [[NumberData]] internal slot - I'm using `Number#toString` for that right now, but others may now be relying on the throw behavior of `Number#valueOf. Wow, awesome catch! Even though I recently implemented https://codereview.appspot.com/198470043 , I completely missed that. To see Caja's current set of dependencies: https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#579 They are: Date.prototype.getDay (Number,Boolean,String).prototype.toString RegExpr.prototype.exec WeakMap.prototype.get If any of these stop throwing, for Caja and SES, that would be a breaking change. Thanks for noticing this! -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Number.prototype not being an instance breaks the web, too
V8 just rolled a change into Canary yesterday that implements the new ES6
semantics for Number.prototype (and Boolean.prototype) being ordinary
objects. Unfortunately, that seems to break the web. In particular
http://jsfiddle.net/#run fails to load now.
What I see happening on that page is a TypeError Number.prototype.valueOf
is not generic being thrown in this function (probably part of moo tools):
Number.prototype.$family = function(){
return isFinite(this) ? 'number' : 'null';
}.hide();
after being invoked on Number.prototype.
AFAICS, that leaves only one option: backing out of this spec change.
(See https://code.google.com/p/chromium/issues/detail?id=476437 for the
bug.)
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.prototype not being an instance breaks the web, too
CCing Piotr.
On Mon, Apr 13, 2015 at 5:37 PM, Mark S. Miller erig...@google.com wrote:
Hold on. I may have reacted too quickly. If it is only jsfiddle, since this
is an online service rather than a widely copied library, they could just
fix it. OTOH, if it really is a mootools issue, then yes, we really do need
to change the spec. (History: Facebook fixed JSON incompatibility. ES5 fixed
Object.prototype.toString.call(null) incompat with jQuery.)
Could someone please reply-all to this thread cc'ing Piotr Zalewa and Oskar
Krawczyk? Thanks.
On Mon, Apr 13, 2015 at 8:26 AM, Mark S. Miller erig...@google.com wrote:
I agree. With Number.prototype joining Array.prototype and
Function.prototype on the dark side, we should ask which others should too.
When it was only Function.prototype and Array.prototype, principle of least
surprise (POLS) had us keep the list as small as possible -- until we had
precisely this kind of evidence of incompatibility. From a security pov, the
important ones not to revert are those carrying mutable state not locked
down by Object.freeze. In ES5 this was only Date.prototype. Of the ES5
builtins in ES6, this now includes RegExp.prototype because of
RegExp.prototype.compile. (Because of de facto stack magic, this might
include Error.prototype as well.) Fotunately, there is still no evidence
that we need to corrupt these as well.
OTOH, POLS still says that almost everything should not go to the dark
side, for consistency with ES6 classes. So the precise line becomes a matter
of taste. I propose that the co-corrupted list be
Function.prototype
Array.prototype
Number.prototype
Boolean.prototype // No incompat data. Only POLS
String.prototype // No incompat data. Only POLS
since Number, Boolean, and String are the ordinary ES5 wrappers of
primitive data values.
For builtins that are new with ES6, clearly there's no compat issue. And
both security and consistency with ES6 classes argue in general for not
corrupting new things. But POLS should put very little weight on the ES5 vs
ES6 difference since post ES6 programmers will just see all of this as JS.
Given that, I could argue Symbol.prototype either way, since Symbol is
kinda another wrapper of a primitive type. But I prefer not. I think we
should keep the list to those 5.
Allen, process-wise, is this too late for ES6? If there's any way this fix
can go in ES6, it should. Otherwise, it should become the first member of
ES6 errata.
All that said, I do find corrupting only Number.prototype to be plausible.
I would not mind if we decided not to spread the corruption even to
Boolean.prototype and String.prototype. If we have to do a last minute
as-small-as-possible change to the spec, to get it into ES6, this might be
best.
On Mon, Apr 13, 2015 at 7:47 AM, Andreas Rossberg rossb...@google.com
wrote:
V8 just rolled a change into Canary yesterday that implements the new ES6
semantics for Number.prototype (and Boolean.prototype) being ordinary
objects. Unfortunately, that seems to break the web. In particular
http://jsfiddle.net/#run fails to load now.
What I see happening on that page is a TypeError
Number.prototype.valueOf is not generic being thrown in this function
(probably part of moo tools):
Number.prototype.$family = function(){
return isFinite(this) ? 'number' : 'null';
}.hide();
after being invoked on Number.prototype.
AFAICS, that leaves only one option: backing out of this spec change.
(See https://code.google.com/p/chromium/issues/detail?id=476437 for the
bug.)
/Andreas
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.prototype not being an instance breaks the web, too
Hold on. I may have reacted too quickly. If it is only jsfiddle, since this
is an online service rather than a widely copied library, they could just
fix it. OTOH, if it really is a mootools issue, then yes, we really do need
to change the spec. (History: Facebook fixed JSON incompatibility. ES5
fixed Object.prototype.toString.call(null) incompat with jQuery.)
Could someone please reply-all to this thread cc'ing Piotr Zalewa and Oskar
Krawczyk? Thanks.
On Mon, Apr 13, 2015 at 8:26 AM, Mark S. Miller erig...@google.com wrote:
I agree. With Number.prototype joining Array.prototype and Function
.prototype on the dark side, we should ask which others should too. When
it was only Function.prototype and Array.prototype, principle of least
surprise (POLS) had us keep the list as small as possible -- until we had
precisely this kind of evidence of incompatibility. From a security pov,
the important ones not to revert are those carrying mutable state not
locked down by Object.freeze. In ES5 this was only Date.prototype. Of the
ES5 builtins in ES6, this now includes RegExp.prototype because of
RegExp.prototype.compile. (Because of de facto stack magic, this might
include Error.prototype as well.) Fotunately, there is still no evidence
that we need to corrupt these as well.
OTOH, POLS still says that almost everything should not go to the dark
side, for consistency with ES6 classes. So the precise line becomes a
matter of taste. I propose that the co-corrupted list be
Function.prototype
Array.prototype
Number.prototype
Boolean.prototype // No incompat data. Only POLS
String.prototype // No incompat data. Only POLS
since Number, Boolean, and String are the ordinary ES5 wrappers of
primitive data values.
For builtins that are new with ES6, clearly there's no compat issue. And
both security and consistency with ES6 classes argue in general for not
corrupting new things. But POLS should put very little weight on the ES5 vs
ES6 difference since post ES6 programmers will just see all of this as JS.
Given that, I could argue Symbol.prototype either way, since Symbol is
kinda another wrapper of a primitive type. But I prefer not. I think we
should keep the list to those 5.
Allen, process-wise, is this too late for ES6? If there's any way this fix
can go in ES6, it should. Otherwise, it should become the first member of
ES6 errata.
All that said, I do find corrupting only Number.prototype to be
plausible. I would not mind if we decided not to spread the corruption even
to Boolean.prototype and String.prototype. If we have to do a last minute
as-small-as-possible change to the spec, to get it into ES6, this might be
best.
On Mon, Apr 13, 2015 at 7:47 AM, Andreas Rossberg rossb...@google.com
wrote:
V8 just rolled a change into Canary yesterday that implements the new ES6
semantics for Number.prototype (and Boolean.prototype) being ordinary
objects. Unfortunately, that seems to break the web. In particular
http://jsfiddle.net/#run fails to load now.
What I see happening on that page is a TypeError
Number.prototype.valueOf is not generic being thrown in this function
(probably part of moo tools):
Number.prototype.$family = function(){
return isFinite(this) ? 'number' : 'null';
}.hide();
after being invoked on Number.prototype.
AFAICS, that leaves only one option: backing out of this spec change.
(See https://code.google.com/p/chromium/issues/detail?id=476437 for the
bug.)
/Andreas
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.prototype not being an instance breaks the web, too
On Apr 13, 2015, at 8:26 AM, Mark S. Miller wrote: ... Allen, process-wise, is this too late for ES6? If there's any way this fix can go in ES6, it should. Otherwise, it should become the first member of ES6 errata. yes, no I have to submit the final version for distribution to the GA today and I'm not gong to make any rash changes in this area. Note there are other approaches to fixing this moo tools issue. For example, Number.prototype.valueOf, instead of throwing if its `this` value does not have a [[NumberData]] internal slot could perform the default valueOf behavior. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.prototype not being an instance breaks the web, too
I agree. With Number.prototype joining Array.prototype and Function
.prototype on the dark side, we should ask which others should too. When it
was only Function.prototype and Array.prototype, principle of least
surprise (POLS) had us keep the list as small as possible -- until we had
precisely this kind of evidence of incompatibility. From a security pov,
the important ones not to revert are those carrying mutable state not
locked down by Object.freeze. In ES5 this was only Date.prototype. Of the
ES5 builtins in ES6, this now includes RegExp.prototype because of
RegExp.prototype.compile. (Because of de facto stack magic, this might
include Error.prototype as well.) Fotunately, there is still no evidence
that we need to corrupt these as well.
OTOH, POLS still says that almost everything should not go to the dark
side, for consistency with ES6 classes. So the precise line becomes a
matter of taste. I propose that the co-corrupted list be
Function.prototype
Array.prototype
Number.prototype
Boolean.prototype // No incompat data. Only POLS
String.prototype // No incompat data. Only POLS
since Number, Boolean, and String are the ordinary ES5 wrappers of
primitive data values.
For builtins that are new with ES6, clearly there's no compat issue. And
both security and consistency with ES6 classes argue in general for not
corrupting new things. But POLS should put very little weight on the ES5 vs
ES6 difference since post ES6 programmers will just see all of this as JS.
Given that, I could argue Symbol.prototype either way, since Symbol is
kinda another wrapper of a primitive type. But I prefer not. I think we
should keep the list to those 5.
Allen, process-wise, is this too late for ES6? If there's any way this fix
can go in ES6, it should. Otherwise, it should become the first member of
ES6 errata.
All that said, I do find corrupting only Number.prototype to be plausible.
I would not mind if we decided not to spread the corruption even to Boolean
.prototype and String.prototype. If we have to do a last minute
as-small-as-possible change to the spec, to get it into ES6, this might be
best.
On Mon, Apr 13, 2015 at 7:47 AM, Andreas Rossberg rossb...@google.com
wrote:
V8 just rolled a change into Canary yesterday that implements the new ES6
semantics for Number.prototype (and Boolean.prototype) being ordinary
objects. Unfortunately, that seems to break the web. In particular
http://jsfiddle.net/#run fails to load now.
What I see happening on that page is a TypeError Number.prototype.valueOf
is not generic being thrown in this function (probably part of moo tools):
Number.prototype.$family = function(){
return isFinite(this) ? 'number' : 'null';
}.hide();
after being invoked on Number.prototype.
AFAICS, that leaves only one option: backing out of this spec change.
(See https://code.google.com/p/chromium/issues/detail?id=476437 for the
bug.)
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.prototype not being an instance breaks the web, too
On Mon, Apr 13, 2015 at 8:37 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Apr 13, 2015, at 8:26 AM, Mark S. Miller wrote: ... Allen, process-wise, is this too late for ES6? If there's any way this fix can go in ES6, it should. Otherwise, it should become the first member of ES6 errata. yes, no I have to submit the final version for distribution to the GA today and I'm not gong to make any rash changes in this area. Note there are other approaches to fixing this moo tools issue. For example, Number.prototype.valueOf, instead of throwing if its `this` value does not have a [[NumberData]] internal slot could perform the default valueOf behavior. Excellent! +1 Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
