Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Mark S. Miller]

On Tue, Jan 27, 2015 at 9:45 PM, Mark S. Miller  wrote:

>
>
> On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky  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 > 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

[Mark S. Miller]

On Tue, Jan 27, 2015 at 7:22 PM, Brendan Eich  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

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Mark S. Miller]

On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky  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  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

[Brendan Eich]

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

[Boris Zbarsky]

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 
.


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

[Brendan Eich]

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

[Axel Rauschmayer]

> On 28 Jan 2015, at 00:06, Brendan Eich  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: Question about Symbols and GlobalSymbolRegistry

[Brendan Eich]

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: Question about Symbols and GlobalSymbolRegistry

[Axel Rauschmayer]

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 
".


> On 27 Jan 2015, at 23:55, Jordan Harband  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  > 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

-- 
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

[Jordan Harband]

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 
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

[Cyrus Najmabadi]

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: Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Mark S. Miller]

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  wrote:

> On 12/4/14 11:49 AM, Mark S. Miller wrote:
>
>> On Thu, Dec 4, 2014 at 2:58 AM, Boris Zbarsky  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: Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Boris Zbarsky]

On 12/4/14 11:49 AM, Mark S. Miller wrote:

On Thu, Dec 4, 2014 at 2:58 AM, Boris Zbarsky  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