Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties
On 12/4/14 11:49 AM, Mark S. Miller wrote:
On Thu, Dec 4, 2014 at 2:58 AM, Boris Zbarsky bzbar...@mit.edu wrote:
OK. What do we do if we discover that throwing from the defineProperty call
with a non-configurable property descriptor is not web-compatible?
What we always do
So just for the record, jQuery (at least all the 2.* versions I've
looked at) contains that following bits:
Data.prototype = {
key: function( owner ) {
...
var descriptor = {},
...
// Secure it in a non-enumerable, non-writable property
try {
descriptor[ this.expando ] = { value: unlock };
Object.defineProperties( owner, descriptor );
// Support: Android 4
// Fallback to a less secure definition
} catch ( e ) {
descriptor[ this.expando ] = unlock;
jQuery.extend( owner, descriptor );
}
This function is called from Data.prototype.get, which is called from
jQuery.event.add. So the upshot is that trying to add an event listener
to the window via the jQuery API will hit this codepath.
Now the good news is that the try/catch _is_ present there, so this
doesn't immediately break sites. But it's something to watch out for,
and we _will_ be changing the behavior of jQuery here in a way that the
jQuery developers clearly think is undesirable.
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties
Yehuda and I just talked about this code and realized that we can allow
this code to proceed on the success path without violating the invariants.
However, this analysis reveals that the intent stated in the comment is
unwarranted, but even that intent can be adequately honored in the scenario
of interest.
The reason why the intent is unwarranted is that the descriptor omits
configurable: rather than explicitly saying configurable: true. If the
owner object already has a configurable own property of the same name, then
a defineProperty where the configurable: is omitted defines an own
property preserving the configurability of the original own property.
Even if owner could not have already had an own property of this name,
owner might be an ES6 proxy whose target is, say, an empty object. The
handler's defineProperty trap could still first define a configurable own
property of this name, and then proceed with the normal logic.
Since the WindowProxy is not a Proxy, or more relevantly, even if it were a
Proxy, the underlying Window is not its target, we can even do the
following:
When the WindowProxy sees the defineProperty with the omitted
configurable: and determines that the underlying Window does not already
have this property. WindowProxy can even preserve the unwarranted intent
expressed in the comment by actually defining a *non-configurable* own
property on the Window itself. However, the behavior of the WindowProxy is
not observably different than our Proxy example: It acts as if it created a
configurable own property on the WindowProxy of this same name, and then
proceeds with the normal defineProperty behavior, which preserves that
alleged configurability.
On Tue, Jan 27, 2015 at 11:48 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/4/14 11:49 AM, Mark S. Miller wrote:
On Thu, Dec 4, 2014 at 2:58 AM, Boris Zbarsky bzbar...@mit.edu wrote:
OK. What do we do if we discover that throwing from the defineProperty
call
with a non-configurable property descriptor is not web-compatible?
What we always do
So just for the record, jQuery (at least all the 2.* versions I've looked
at) contains that following bits:
Data.prototype = {
key: function( owner ) {
...
var descriptor = {},
...
// Secure it in a non-enumerable, non-writable
property
try {
descriptor[ this.expando ] = { value:
unlock };
Object.defineProperties( owner, descriptor
);
// Support: Android 4
// Fallback to a less secure definition
} catch ( e ) {
descriptor[ this.expando ] = unlock;
jQuery.extend( owner, descriptor );
}
This function is called from Data.prototype.get, which is called from
jQuery.event.add. So the upshot is that trying to add an event listener to
the window via the jQuery API will hit this codepath.
Now the good news is that the try/catch _is_ present there, so this
doesn't immediately break sites. But it's something to watch out for, and
we _will_ be changing the behavior of jQuery here in a way that the jQuery
developers clearly think is undesirable.
-Boris
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Symbols and GlobalSymbolRegistry
On 28 Jan 2015, at 00:06, Brendan Eich bren...@mozilla.org wrote: Axel Rauschmayer wrote: It may make sense to add them. Their identifiers would have to be as unambiguous as possible, e.g. URIs such as http://ecmascript.org/symbol/foo;. Symbol.iterator and the other well-known symbols are self-same in all connected realms. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-well-known-symbols. So there's no need for this There is one use case (admittedly a rather hypothetical one): serializing the Symbol.* symbols to a text format (e.g. an encoding in JSON). (and URLs suck for such things; plus, you probably mean URIs, but I don't care enough to check!). Yes, I mean URIs(?) -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties
On 1/27/15 4:44 PM, Mark S. Miller wrote: Since the WindowProxy is not a Proxy, or more relevantly, even if it were a Proxy, the underlying Window is not its target, we can even do the following: When the WindowProxy sees the defineProperty with the omitted configurable: and determines that the underlying Window does not already have this property. WindowProxy can even preserve the unwarranted intent expressed in the comment by actually defining a *non-configurable* own property on the Window itself. However, the behavior of the WindowProxy is not observably different than our Proxy example: It acts as if it created a configurable own property on the WindowProxy of this same name, and then proceeds with the normal defineProperty behavior, which preserves that alleged configurability. I'd like to understand better the suggestion here, because I'm not sure I'm entirely following it. Specifically, I'd like to understand it in terms of the internal methods defined by https://github.com/domenic/window-proxy-spec. Presumably you're proposing that we keep all of that as-is except for [[DefineOwnProperty]], right? For [[DefineOwnProperty]], are we basically talking about changing step 1 to: 1) If the [[Configurable]] field of Desc is present and Desc.[[Configurable]] is false, then throw a TypeError exception. while keeping everything else as-is, as opposed to the behavior I'd understood we were aiming for, which was: 1) If the [[Configurable]] field of Desc is not present or Desc.[[Configurable]] is false, then throw a TypeError exception. ? If so, that's certainly a change that is much more likely to be web-compatible... -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Symbols and GlobalSymbolRegistry
They are not - if they were, then adding a new well-known symbol like
Symbol.foo would fail if anyone had code that did `Symbol.for('foo')`. (I
have no idea if that is the reason, but certainly that's a reason not to
make them available via the registry)
On Tue, Jan 27, 2015 at 2:32 PM, Cyrus Najmabadi cyr...@microsoft.com
wrote:
Hi esdiscuss. A couple more questions.
1) Are the built-in symbols (like ‘Symbol.iterator’) in the
GlobalSymbolRegsitry?
2) If so, what are their keys? i.e. how would one reach
Symbol.iterator using Symbol.for(…)?
Thanks!
-- Cyrus
*From:* Kevin Smith [mailto:zenpars...@gmail.com]
*Sent:* Wednesday, January 21, 2015 5:16 PM
*To:* Cyrus Najmabadi
*Cc:* Jason Freeman; es-discuss
*Subject:* Re: Question about Symbols and GlobalSymbolRegistry
Am I understanding correctly?
Yes. The argument to the Symbol constructor is just a descriptive string.
___
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: Question about Symbols and GlobalSymbolRegistry
Hi esdiscuss. A couple more questions. 1) Are the built-in symbols (like ‘Symbol.iterator’) in the GlobalSymbolRegsitry? 2) If so, what are their keys? i.e. how would one reach Symbol.iterator using Symbol.for(…)? Thanks! -- Cyrus From: Kevin Smith [mailto:zenpars...@gmail.com] Sent: Wednesday, January 21, 2015 5:16 PM To: Cyrus Najmabadi Cc: Jason Freeman; es-discuss Subject: Re: Question about Symbols and GlobalSymbolRegistry Am I understanding correctly? Yes. The argument to the Symbol constructor is just a descriptive string. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Symbols and GlobalSymbolRegistry
Axel Rauschmayer wrote: So there's no need for this There is one use case (admittedly a rather hypothetical one): serializing the Symbol.* symbols to a text format (e.g. an encoding in JSON). Symbols that user-code puts into the registry do not serialize this way, so why should the well-known ones? If you want to write a JSON helper-pair (toJSON or a replacer, with a correponding reviver, I think), then you can indeed serialize and deserialize symbols. But there's no ES6 backstage default-wiring from JSON to Symbol.for/keyFor. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Symbols and GlobalSymbolRegistry
It may make sense to add them. Their identifiers would have to be as
unambiguous as possible, e.g. URIs such as http://ecmascript.org/symbol/foo
http://ecmascript.org/symbol/foo.
On 27 Jan 2015, at 23:55, Jordan Harband ljh...@gmail.com wrote:
They are not - if they were, then adding a new well-known symbol like
Symbol.foo would fail if anyone had code that did `Symbol.for('foo')`. (I
have no idea if that is the reason, but certainly that's a reason not to make
them available via the registry)
On Tue, Jan 27, 2015 at 2:32 PM, Cyrus Najmabadi cyr...@microsoft.com
mailto:cyr...@microsoft.com wrote:
Hi esdiscuss. A couple more questions.
1) Are the built-in symbols (like ‘Symbol.iterator’) in the
GlobalSymbolRegsitry?
2) If so, what are their keys? i.e. how would one reach Symbol.iterator
using Symbol.for(…)?
Thanks!
-- Cyrus
From: Kevin Smith [mailto:zenpars...@gmail.com mailto:zenpars...@gmail.com]
Sent: Wednesday, January 21, 2015 5:16 PM
To: Cyrus Najmabadi
Cc: Jason Freeman; es-discuss
Subject: Re: Question about Symbols and GlobalSymbolRegistry
Am I understanding correctly?
Yes. The argument to the Symbol constructor is just a descriptive string.
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Symbols and GlobalSymbolRegistry
Axel Rauschmayer wrote: It may make sense to add them. Their identifiers would have to be as unambiguous as possible, e.g. URIs such as http://ecmascript.org/symbol/foo;. Symbol.iterator and the other well-known symbols are self-same in all connected realms. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-well-known-symbols. So there's no need for this (and URLs suck for such things; plus, you probably mean URIs, but I don't care enough to check!). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties
Mark S. Miller wrote: The reason why the intent is unwarranted is that the descriptor omits configurable: rather than explicitly saying configurable: true. If the owner object already has a configurable own property of the same name, then a defineProperty where the configurable: is omitted defines an own property preserving the configurability of the original own property. Wild, and genius. How many more narrow escapes can we make and keep both web compat and integrity? :-P Is there any downside? What is the bad case that observably changes behavior, if any (not involving proxies)? I'm too tired to search the state space right now, throwing this out as a challenge. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties
On Tue, Jan 27, 2015 at 9:45 PM, Mark S. Miller erig...@google.com wrote: On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/27/15 4:44 PM, Mark S. Miller wrote: Since the WindowProxy is not a Proxy, or more relevantly, even if it were a Proxy, the underlying Window is not its target, we can even do the following: When the WindowProxy sees the defineProperty with the omitted configurable: and determines that the underlying Window does not already have this property. WindowProxy can even preserve the unwarranted intent expressed in the comment by actually defining a *non-configurable* own property on the Window itself. However, the behavior of the WindowProxy is not observably different than our Proxy example: It acts as if it created a configurable own property on the WindowProxy of this same name, and then proceeds with the normal defineProperty behavior, which preserves that alleged configurability. I'd like to understand better the suggestion here, because I'm not sure I'm entirely following it. Specifically, I'd like to understand it in terms of the internal methods defined by https://github.com/domenic/ window-proxy-spec. Presumably you're proposing that we keep all of that as-is except for [[DefineOwnProperty]], right? For [[DefineOwnProperty]], are we basically talking about changing step 1 to: 1) If the [[Configurable]] field of Desc is present and Desc.[[Configurable]] is false, then throw a TypeError exception. while keeping everything else as-is, Exactly correct. I didn't realize until reading your reply is that this is all that's necessary -- that it successfully covers all the cases I was thinking about without any further case division. Here's another option, not clearly better or worse: [[DefineOwnProperty]] (P, Desc) 1. let R be the result of calling the [[DefineOwnProperty]] internal method of *W* with arguments *P* and *Desc*. 2. If *desc*.[[Configurable]] is present and *false*, then throw a *TypeError* exception. 3. return R. This is exactly like your solution, but with the order of the two steps switched. Perhaps the next breakage we see will tell us which of these to choose. If both are web compatible, then we need only pick which one we like better. as opposed to the behavior I'd understood we were aiming for, which was: 1) If the [[Configurable]] field of Desc is not present or Desc.[[Configurable]] is false, then throw a TypeError exception. ? If so, that's certainly a change that is much more likely to be web-compatible... Good! It certainly takes care of the one concrete breakage we know about so far. -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties
On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/27/15 4:44 PM, Mark S. Miller wrote: Since the WindowProxy is not a Proxy, or more relevantly, even if it were a Proxy, the underlying Window is not its target, we can even do the following: When the WindowProxy sees the defineProperty with the omitted configurable: and determines that the underlying Window does not already have this property. WindowProxy can even preserve the unwarranted intent expressed in the comment by actually defining a *non-configurable* own property on the Window itself. However, the behavior of the WindowProxy is not observably different than our Proxy example: It acts as if it created a configurable own property on the WindowProxy of this same name, and then proceeds with the normal defineProperty behavior, which preserves that alleged configurability. I'd like to understand better the suggestion here, because I'm not sure I'm entirely following it. Specifically, I'd like to understand it in terms of the internal methods defined by https://github.com/domenic/ window-proxy-spec. Presumably you're proposing that we keep all of that as-is except for [[DefineOwnProperty]], right? For [[DefineOwnProperty]], are we basically talking about changing step 1 to: 1) If the [[Configurable]] field of Desc is present and Desc.[[Configurable]] is false, then throw a TypeError exception. while keeping everything else as-is, Exactly correct. I didn't realize until reading your reply is that this is all that's necessary -- that it successfully covers all the cases I was thinking about without any further case division. as opposed to the behavior I'd understood we were aiming for, which was: 1) If the [[Configurable]] field of Desc is not present or Desc.[[Configurable]] is false, then throw a TypeError exception. ? If so, that's certainly a change that is much more likely to be web-compatible... Good! It certainly takes care of the one concrete breakage we know about so far. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties
On Tue, Jan 27, 2015 at 7:22 PM, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
The reason why the intent is unwarranted is that the descriptor omits
configurable: rather than explicitly saying configurable: true. If the
owner object already has a configurable own property of the same name, then
a defineProperty where the configurable: is omitted defines an own
property preserving the configurability of the original own property.
Wild, and genius.
(blush)
How many more narrow escapes can we make and keep both web compat and
integrity? :-P
How many will we need? ;)
Is there any downside? What is the bad case that observably changes
behavior, if any (not involving proxies)?
You get the following non-intuitive but allowed behavior.
if (!hasOwnProperty(W, P)) {
defineProperty(W, P, { value: V })
console.log(getOwnPropertyDescriptor(W, P).configurable); // true
}
However, you could also get this behavior if W is a proxy, so it doesn't
introduce any new cases beyond what's already possible. It is only
surprising.
That's not much of a downside, and I can't think of any other downside.
I'm too tired to search the state space right now, throwing this out as a
challenge.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
