Re: A DOM use case that can't be emulated with direct proxies
2012/12/12 Kevin Reid kpr...@google.com On Wed, Dec 12, 2012 at 12:35 PM, David Bruant bruan...@gmail.com wrote: I was a bit too strong in my statement, sorry. Let me rephrase: the internal [[Target]] can't be changed, but a proxy can emulate changing of fake target as long as what happens with this fake target doesn't involve invariant checking. That's the reason I was suggesting that WindowProxies could (maybe depending on how the object reference was obtained) throw whenever invariant checks are involved. Exactly. So a user-defined switching proxy needs only to: 1. refuse to commit to any invariant (non-configurable property or preventExtensions) 2. even if its switchable-target has an invariant, do not expose that invariant (i.e. pretend each property is configurable) Sorry for arriving late to this thread. The solution that Kevin described is also how I would approach a retargetable proxy (i.e. a proxy that can wrap different target objects over time). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
2012/12/13 David Bruant bruan...@gmail.com
Le 13/12/2012 20:47, Jason Orendorff a écrit :
David: https://gist.github.com/4279162
I think this is what Kevin has in mind. Note in particular that the target
of the Proxy is just a dummy object, and the handler ignores it entirely.
The proxy uses it for invariant checks, but the intent is that those would
always pass.
but they do not; try:
var [p, setTarget] = retargetableProxy({}); // I love destructuring
sooo much!
Object.defineProperty(p, 'a', {configurable: false, value:31});
setTarget({});
Object.getOwnPropertyDescriptor(p, 'a'); // invariant check throws here
Any variant that can be written will have the same issue. Even trickeries
with the defineProperty trap.
The proxy is enforcing invariants against the dummy [[target]]. The same
is to be expected from WindowProxy instances even if their underlying
window changes. It doesn't matter if the invariant is enforced on the dummy
target on an actual window instance. It is enforced and that's the
problem (with WindowProxy implemented as they are now not being emulable
with proxies)
To clarify, there won't be any invariant violations if you ensure all three
of the following conditions hold:
a) the dummy target object never acquires any invariants (letting it be a
dummy empty object and otherwise ignoring the target completely achieves
that)
b) handler traps that *query* the proxy never reveal any invariants, even
if the real target currently pointed-to has invariants (i.e.
getOwnPropertyDescriptor always changes the returned property descriptor's
configurable attribute to true, isExtensible always returns false, etc.)
c) handler traps that *update* the proxy refuse to commit
(preventExtensions throws, defineProperty returns false when dealing with
configurable:false properties, ...)
It's a heavyweight way of going about things, but as Brandon mentioned,
it's the price to pay for wanting to do weird things no normal ES5 object
could ever do. The more a proxy's behavior deviates from that of an ES5
object, the uglier its implementation will be to circumvent the invariant
checks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
2012/12/13 Kevin Reid kpr...@google.com Yes, exactly. I was just this minute in the process of writing such a proxy myself, and have not yet confirmed whether it is accepted by the invariant checks for all the cases I'm thinking of (testing against FF 18.0). Note that either (1) all the switched-among targets need to have the same [[Prototype]], (2) the proxy has to pretend that all inherited properties are actually own, (3) or mutating [[Prototype]] (i.e. __proto__) needs to be possible. In my particular use case, (1) is not a suitable option, so I would implement (2) if (3) is not available. Not that I approve of (3), but one does what one must to accomplish virtualization. It's worth noting that direct proxies do not enforce any invariants w.r.t. inherited property access/update. For instance, the get trap is allowed to return arbitrary values over time for a non-configurable, non-writable *inherited* property. In other words, it's as if direct proxies always have a mutable __proto__ (even if Object.getPrototypeOf returns a stable result). Hence, (3) is the best way to rationalize the behavior of direct proxies. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
2012/12/14 Mark S. Miller erig...@google.com On Fri, Dec 14, 2012 at 10:19 AM, Brendan Eich bren...@mozilla.com wrote: David Bruant wrote: Le 14/12/2012 08:25, Brendan Eich a écrit : window.location can be set by assignment to navigate to a new URL. location is [Unforgeable, PutForward], so it should be reflected as a non-configurable getter+setter according to WebIDL. [...] Nevertheless, since ES5-standard reflection is new, I doubt anyone cares that location appears to be a data property. It should be an accessor. But it needs to be non-configurable, so we still have a problem -- or do we? AFAICT, a non-configurable accessor fits all the constraints. Also, when emulating this property using a proxy, reflecting it as a non-configurable accessor will not violate any proxy invariants, so this is good. However, regarding the retargetable proxy pattern put forward by Kevin and Jason to emulate WindowProxy, that implementation cannot accurately expose window.location as non-configurable, but would need to expose it as configurable instead. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 14/12/2012 08:25, Brendan Eich a écrit : Mark S. Miller wrote: On Thu, Dec 13, 2012 at 7:05 PM, Brendan Eichbren...@secure.meer.net wrote: Boris Zbarsky pointed out on public-script-coord that window.location and window.document must be non-configurable _ab initio_, but perhaps this is achievable with direct proxies? This resolved into two suggestions, both consistent with ES5 and with direct proxies: * windows.document and window.location must refuse to be configured, but they can still claim to be configurable. ES5 purposely forbids only the opposite mismatch: They can't claim to be non-configurable but still change state in ways that violate that claim. * Allen suggested that these could be non-configurable getter-only accessor properties, To be more specific, [Unforgeable] properties would be described by non-configurable getter-only properties. window.location can be set by assignment to navigate to a new URL. location is [Unforgeable, PutForward], so it should be reflected as a non-configurable getter+setter according to WebIDL. Yet it appears in Chrome, Firefox, Opera, and Safari to be a writable data property. oh, web browsers and standards... There is indeed a pretty violent mismatch between WebIDL and reality, I guess. Specifically because of the behavior you're describing (assigning window.location having a behavior), location ought to be an accessor. What was the rationale that motivated all these browsers to go for data property? Is it still time to change this behavior? David In any event, it can't be a getter-only accessor. /be where the getter stays the same and the magic switching behavior is in the getter. (My words for Allen's suggestion) Either is fine. I like Allen's better. -- 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: A DOM use case that can't be emulated with direct proxies
On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 14/12/2012 11:01, Andreas Rossberg a écrit : On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. I still believe the tests belong to HTML DOM, but it wouldn't be absurd to test this inside of test262. The invariants are an ES5 device. I think it makes sense for ES5 to say we noticed that some platforms were defining host objects not respecting the invariants; here is how they were wrong. The invariants are a not-well-known and yet normative part of the spec. Offering some guidance in test262 on this part would be good I think. I would organize things the following way: inside of the /test/suite directory bestPractice/ ch06/ .. ch15/ intl402/ platformSpecific/ readme (explains why this directory is here and what the different subdirectories are for) webBrowser/ readme (to explain how to run each test) test1 ... testn And if different platforms use ES5, but do not conform, platformSpecific subdirectories can be added to test the non-conforming host objects on the different platforms. Each platform test can contain any sort of file, not just JS. For instance, in the case being discussed, it would make sense to create several HTML files some defining iframes, other defining iframe contents. d8 or jsc would just have to skip the platformSpecific directory. I think it's a decent trade-off to explain how invariants should work on self-objects without polluting the test suite. [cc'ing test262] David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
+1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.comjavascript:; wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.comjavascript:; wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org javascript:; https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Regarding what Andreas said and what Alex +1ed, we already have precedent. We already argued through this precedent in committee and agreed. I like David's suggestion about how to organize these tests. On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell slightly...@google.comwrote: +1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ 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 -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On 14 December 2012 16:54, Mark Miller erig...@gmail.com wrote: Regarding what Andreas said and what Alex +1ed, we already have precedent. We already argued through this precedent in committee and agreed. I like David's suggestion about how to organize these tests. Hm, unless you are talking about intl402, I wasn't aware of that. What's the precedent? If the non ES tests are separated properly then it's probably less of an issue, though I still prefer that such tests are under a different umbrella. Just to make clear that they are not actually testing ES engines. That is, I'd much rather have a structure like (modulo details of naming): estests/ test262/ ch*/ intl402/ platforms/ /Andreas On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell slightly...@google.com wrote: +1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ 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 -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Fri, Dec 14, 2012 at 8:36 AM, Andreas Rossberg rossb...@google.comwrote: On 14 December 2012 16:54, Mark Miller erig...@gmail.com wrote: Regarding what Andreas said and what Alex +1ed, we already have precedent. We already argued through this precedent in committee and agreed. I like David's suggestion about how to organize these tests. Hm, unless you are talking about intl402, I wasn't aware of that. What's the precedent? I will find it when I have time. If anyone else finds it first, please post a link. Thanks. If the non ES tests are separated properly then it's probably less of an issue, though I still prefer that such tests are under a different umbrella. Just to make clear that they are not actually testing ES engines. That is, I'd much rather have a structure like (modulo details of naming): estests/ test262/ ch*/ intl402/ platforms/ The violation is a violation of the normative ES-262 5.1 spec. Host objects as exposed to ES are part of the TCB, and constrained by the ES spec. The ES spec is does not just constrain ES engines. If you want to make a separate engines/ subdirectory of test262/ and move all the engine-only tests there, I would not object. But I also would not recommend bothering. /Andreas On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell slightly...@google.com wrote: +1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ 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 -- Text by me above is hereby placed in the public domain Cheers, --MarkM -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Fri, Dec 14, 2012 at 9:12 AM, Mark Miller erig...@gmail.com wrote: On Fri, Dec 14, 2012 at 8:36 AM, Andreas Rossberg rossb...@google.com wrote: On 14 December 2012 16:54, Mark Miller erig...@gmail.com wrote: Regarding what Andreas said and what Alex +1ed, we already have precedent. We already argued through this precedent in committee and agreed. I like David's suggestion about how to organize these tests. Hm, unless you are talking about intl402, I wasn't aware of that. What's the precedent? I will find it when I have time. If anyone else finds it first, please post a link. Thanks. http://hg.ecmascript.org/tests/test262/file/c84161250e66/test/suite/ch15/15.2/15.2.3/15.2.3.6/S15.2.3.6_A1.js If the non ES tests are separated properly then it's probably less of an issue, though I still prefer that such tests are under a different umbrella. Just to make clear that they are not actually testing ES engines. That is, I'd much rather have a structure like (modulo details of naming): estests/ test262/ ch*/ intl402/ platforms/ The violation is a violation of the normative ES-262 5.1 spec. Host objects as exposed to ES are part of the TCB, and constrained by the ES spec. The ES spec is does not just constrain ES engines. If you want to make a separate engines/ subdirectory of test262/ and move all the engine-only tests there, I would not object. But I also would not recommend bothering. /Andreas On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell slightly...@google.com wrote: +1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ 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 -- Text by me above is hereby placed in the public domain Cheers, --MarkM -- Text by me above is hereby placed in the public domain Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
David Bruant wrote: Le 14/12/2012 08:25, Brendan Eich a écrit : window.location can be set by assignment to navigate to a new URL. location is [Unforgeable, PutForward], so it should be reflected as a non-configurable getter+setter according to WebIDL. That would be correct -- and nice, I agree. Yet it appears in Chrome, Firefox, Opera, and Safari to be a writable data property. oh, web browsers and standards... There is indeed a pretty violent mismatch between WebIDL and reality, I guess. Specifically because of the behavior you're describing (assigning window.location having a behavior), location ought to be an accessor. What was the rationale that motivated all these browsers to go for data property? Is it still time to change this behavior? Let's not make the standards-are-prior-to-implementations mistake. All this came from Netscape 2, JS1. It got cloned by IE and other browsers. It mutated and was not standardized until a decade later, in HTML5 and then DOM4 -- and WebIDL is an even later (still not REC, it's in CR if I recall correctly) standard. Nevertheless, since ES5-standard reflection is new, I doubt anyone cares that location appears to be a data property. It should be an accessor. But it needs to be non-configurable, so we still have a problem -- or do we? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Fri, Dec 14, 2012 at 10:19 AM, Brendan Eich bren...@mozilla.com wrote: David Bruant wrote: Le 14/12/2012 08:25, Brendan Eich a écrit : window.location can be set by assignment to navigate to a new URL. location is [Unforgeable, PutForward], so it should be reflected as a non-configurable getter+setter according to WebIDL. That would be correct -- and nice, I agree. Yet it appears in Chrome, Firefox, Opera, and Safari to be a writable data property. oh, web browsers and standards... There is indeed a pretty violent mismatch between WebIDL and reality, I guess. Specifically because of the behavior you're describing (assigning window.location having a behavior), location ought to be an accessor. What was the rationale that motivated all these browsers to go for data property? Is it still time to change this behavior? Let's not make the standards-are-prior-to-implementations mistake. All this came from Netscape 2, JS1. It got cloned by IE and other browsers. It mutated and was not standardized until a decade later, in HTML5 and then DOM4 -- and WebIDL is an even later (still not REC, it's in CR if I recall correctly) standard. Nevertheless, since ES5-standard reflection is new, I doubt anyone cares that location appears to be a data property. It should be an accessor. But it needs to be non-configurable, so we still have a problem -- or do we? AFAICT, a non-configurable accessor fits all the constraints. /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Mark S. Miller wrote: Nevertheless, since ES5-standard reflection is new, I doubt anyone cares that location appears to be a data property. It should be an accessor. But it needs to be non-configurable, so we still have a problem -- or do we? AFAICT, a non-configurable accessor fits all the constraints. Great! Let's do that then. Can someone bring this to public-script-coord or where-ever else might be the best venue for getting implementors on board? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 14/12/2012 19:04, Mark S. Miller a écrit : On Fri, Dec 14, 2012 at 9:12 AM, Mark Miller erig...@gmail.com wrote: On Fri, Dec 14, 2012 at 8:36 AM, Andreas Rossberg rossb...@google.com wrote: On 14 December 2012 16:54, Mark Miller erig...@gmail.com wrote: Regarding what Andreas said and what Alex +1ed, we already have precedent. We already argued through this precedent in committee and agreed. I like David's suggestion about how to organize these tests. Hm, unless you are talking about intl402, I wasn't aware of that. What's the precedent? I will find it when I have time. If anyone else finds it first, please post a link. Thanks. http://hg.ecmascript.org/tests/test262/file/c84161250e66/test/suite/ch15/15.2/15.2.3/15.2.3.6/S15.2.3.6_A1.js Yes, this probably belongs somewhere else that the ch15 directory. For any other ECMAScript 5.1 implementation, there is no particular reason to consider the document global differently than any other. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 13/12/2012 00:51, Mark S. Miller a écrit : On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.com wrote: [...] * change the behavior of WindowProxy instances when it comes to doing things that would commit them to eternal invariants to throw instead of forwarding. This solution may still be possible, because it's unlikely that Object.defineProperty is widely used in web content today. But this change should happen pretty fast before content relies on it. I think this is the only viable solution. Ok. What do you think of the idea of different handlers based on context? [1] The current behavior violates ES5 in an unintended way[1]. Just to clarify, invariants described in ES5.1 - 8.6.2 are violated. As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. I'll reach out to public-script-coord to re-explain the issue and the suggested changes. I'll write a test case, submit it to the webapps directory [2] (I'll ask first to be sure it's the right one) and file bugs in different browsers. David [1] Last point of https://mail.mozilla.org/pipermail/es-discuss/2012-December/027092.html [2] http://dvcs.w3.org/hg/webapps/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: I think this is the only viable solution. Ok. What do you think of the idea of different handlers based on context? [1] [1] Last point of https://mail.mozilla.org/pipermail/es-discuss/2012-December/027092.html Only if these different way of obtaining the object actually obtain different objects. The current behavior violates ES5 in an unintended way[1]. Just to clarify, invariants described in ES5.1 - 8.6.2 are violated. yes. As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. The modern versions of all major browsers (IE, Chrome, FF, Safari, Opera) all do so close to perfect on test262 that even adding one additional test failure creates a significant incentive to fix it -- especially since the others will. Of course, it would also be good to get the HTML5 spec fixed and to get such tests into HTML/DOM test suites. But I'm not holding my breath. Your observation about needing to get this fixed soon in right, so let's move on test262 first. I'll reach out to public-script-coord to re-explain the issue and the suggested changes. I'll write a test case, submit it to the webapps directory [2] (I'll ask first to be sure it's the right one) and file bugs in different browsers. Thanks! David [2] http://dvcs.w3.org/hg/webapps/ -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Something I just posted in the public-script-coord thread bears repeating here: A single invariant-violating object can be leveraged by direct proxies to create any number of other objects that also violate invariants. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Thu, Dec 13, 2012 at 11:47 AM, Jason Orendorff jason.orendo...@gmail.com wrote: This target, even if dummy, is the one that will be used for invariants checks. You can't get away from this by design. This is one of the most important part of the direct proxies design. Even if you switch of fake target, the engine will still perform checks on the dummy internal [[Target]]. I feel we're cycling in what we say and I feel I can't find the right words to explain my point. One idea would be for you to implement a target-switching proxy based on direct proxies (Firefox has them natively or you can use Tom's shim [1]). I'm confident you'll understand my point through this exercise. David: https://gist.github.com/4279162 I think this is what Kevin has in mind. Note in particular that the target of the Proxy is just a dummy object, and the handler ignores it entirely. The proxy uses it for invariant checks, but the intent is that those would always pass. Yes, exactly. I was just this minute in the process of writing such a proxy myself, and have not yet confirmed whether it is accepted by the invariant checks for all the cases I'm thinking of (testing against FF 18.0). Note that either (1) all the switched-among targets need to have the same [[Prototype]], (2) the proxy has to pretend that all inherited properties are actually own, (3) or mutating [[Prototype]] (i.e. __proto__) needs to be possible. In my particular use case, (1) is not a suitable option, so I would implement (2) if (3) is not available. Not that I approve of (3), but one does what one must to accomplish virtualization. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 13/12/2012 20:47, Jason Orendorff a écrit :
On Wed, Dec 12, 2012 at 3:44 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/12/2012 22:30, Kevin Reid a écrit :
The JS runtime won't know that the proxy has anything to do with
the actual Window instance. The Proxy's formal target will be
just {};
This target, even if dummy, is the one that will be used for
invariants checks. You can't get away from this by design. This is
one of the most important part of the direct proxies design.
Even if you switch of fake target, the engine will still perform
checks on the dummy internal [[Target]].
I feel we're cycling in what we say and I feel I can't find the
right words to explain my point. One idea would be for you to
implement a target-switching proxy based on direct proxies
(Firefox has them natively or you can use Tom's shim [1]). I'm
confident you'll understand my point through this exercise.
David: https://gist.github.com/4279162
I think this is what Kevin has in mind. Note in particular that the
target of the Proxy is just a dummy object, and the handler ignores it
entirely. The proxy uses it for invariant checks, but the intent is
that those would always pass.
but they do not; try:
var [p, setTarget] = retargetableProxy({}); // I love destructuring
sooo much!
Object.defineProperty(p, 'a', {configurable: false, value:31});
setTarget({});
Object.getOwnPropertyDescriptor(p, 'a'); // invariant check throws here
Any variant that can be written will have the same issue. Even
trickeries with the defineProperty trap.
The proxy is enforcing invariants against the dummy [[target]]. The same
is to be expected from WindowProxy instances even if their underlying
window changes. It doesn't matter if the invariant is enforced on the
dummy target on an actual window instance. It is enforced and that's the
problem (with WindowProxy implemented as they are now not being
emulable with proxies)
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Thu, Dec 13, 2012 at 2:58 PM, David Bruant bruan...@gmail.com wrote:
Le 13/12/2012 20:47, Jason Orendorff a écrit :
David: https://gist.github.com/4279162
I think this is what Kevin has in mind. Note in particular that the target
of the Proxy is just a dummy object, and the handler ignores it entirely.
The proxy uses it for invariant checks, but the intent is that those would
always pass.
but they do not; try:
var [p, setTarget] = retargetableProxy({}); // I love destructuring
sooo much!
Object.defineProperty(p, 'a', {configurable: false, value:31});
In my proposal, this would fail (refuse to commit to any invariant as I
put it above). The handler specifically refuses anything non-configurable
or non-writable-data.
setTarget({});
Object.getOwnPropertyDescriptor(p, 'a'); // invariant check throws here
Any variant that can be written will have the same issue. Even trickeries
with the defineProperty trap.
The proxy is enforcing invariants against the dummy [[target]]. The same
is to be expected from WindowProxy instances even if their underlying
window changes. It doesn't matter if the invariant is enforced on the dummy
target on an actual window instance. It is enforced and that's the
problem (with WindowProxy implemented as they are now not being emulable
with proxies)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Kevin Reid wrote: (2) the proxy has to pretend that all inherited properties are actually own, It strikes me that we need this for window objects anyway, to resolve https://bugs.ecmascript.org/show_bug.cgi?id=78 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Thu, Dec 13, 2012 at 7:05 PM, Brendan Eich bren...@secure.meer.net wrote: Boris Zbarsky pointed out on public-script-coord that window.location and window.document must be non-configurable _ab initio_, but perhaps this is achievable with direct proxies? This resolved into two suggestions, both consistent with ES5 and with direct proxies: * windows.document and window.location must refuse to be configured, but they can still claim to be configurable. ES5 purposely forbids only the opposite mismatch: They can't claim to be non-configurable but still change state in ways that violate that claim. * Allen suggested that these could be non-configurable getter-only accessor properties, where the getter stays the same and the magic switching behavior is in the getter. (My words for Allen's suggestion) Either is fine. I like Allen's better. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
David Bruant wrote:
Le 12/12/2012 21:42, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 12:35 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
I was a bit too strong in my statement, sorry. Let me rephrase:
the internal [[Target]] can't be changed, but a proxy can emulate
changing of fake target as long as what happens with this
fake target doesn't involve invariant checking.
That's the reason I was suggesting that WindowProxies could
(maybe depending on how the object reference was obtained) throw
whenever invariant checks are involved.
Exactly. So a user-defined switching proxy needs only to:
1. refuse to commit to any invariant (non-configurable property or
preventExtensions)
2. even if its switchable-target has an invariant, do not expose that
invariant (i.e. pretend each property is configurable)
Pretend that something non-configurable actually is configurable is an
invariant violation. To be more concrete:
* There is an webpage with an iframe
* The same window object is proxied by 2 WindowProxy instances. One
outside the iframe, one inside.
Just as a point of fact regarding the web-as-it-is, this can't happen,
right? There's only one WindowProxy per Window and it is the only object
referenced by any JS variable. JS code cannot construct another aliasing
WindowProxy.
* Inside of the iframe, scripts can add a non-configurable property
azerty to their global.
Boris Zbarsky pointed out on public-script-coord that window.location
and window.document must be non-configurable _ab initio_, but perhaps
this is achievable with direct proxies?
/be
* Outside the iframe, what happens when
Object.getOwnPropertyDescriptor(iframeWindow, 'azerty') is called?
You're suggesting that {configurable: true} is returned. The problem
is that on the actual Window instance, there is a non-configurable
property, so if the WindowProxy handler tries to do that, an error
will be thrown because of invariant checks.
I think throwing is the correct behavior here. The handler can't tell
the truth about non-configurable properties (because a later different
target may not have the same non-configurable properties), but also
can't lie, because lies involves throwing... well, since I say that
throwing is the correct behavior, I guess lying is too in a way.
David
___
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: A DOM use case that can't be emulated with direct proxies
Mark S. Miller wrote: On Thu, Dec 13, 2012 at 7:05 PM, Brendan Eichbren...@secure.meer.net wrote: Boris Zbarsky pointed out on public-script-coord that window.location and window.document must be non-configurable _ab initio_, but perhaps this is achievable with direct proxies? This resolved into two suggestions, both consistent with ES5 and with direct proxies: * windows.document and window.location must refuse to be configured, but they can still claim to be configurable. ES5 purposely forbids only the opposite mismatch: They can't claim to be non-configurable but still change state in ways that violate that claim. * Allen suggested that these could be non-configurable getter-only accessor properties, window.location can be set by assignment to navigate to a new URL. Yet it appears in Chrome, Firefox, Opera, and Safari to be a writable data property. In any event, it can't be a getter-only accessor. /be where the getter stays the same and the magic switching behavior is in the getter. (My words for Allen's suggestion) Either is fine. I like Allen's better. -- 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
A DOM use case that can't be emulated with direct proxies
Hi, A good question by Anne van Kesteren [1] followed by good remarks by Boris Zbarsky [2][3] made me try a little something [4][5]. The WindowProxy object returned as the 'contentWindow' property of iframes never changes; whatever you do when changing the @src, always the same object is returned. However, based on whether the @src is changed, the WindowProxy proxies to a different Window instance. I thing this is something that can't be implemented with direct proxies. Is this conclusion shared? Assuming I'm not wrong in my analysis, now is time to wonder if the direct proxy design should be change to make this part writable in JavaScript. If self-hosting the browser APIs as pure ECMAScript 6 is a goal, something needs to be changed indeed. If it's possible to relax this use case a little bit, following the direct proxies model described some time ago [6], it would be possible to do the following: * Model WindowProxy objects as ES proxies * Allow the UA to change the target of this proxy at will (which is very close to what's actually done and spec'ed anyway) I wish to point out that apparently iframe.contentWindow does break quite a lot of eternal invariants [7] which isn't really good news, because it questions their eternity. Among alternatives I'm thinking of: * define a new type of proxies for which the target can be changed (either only as a spec device of as an actual object that can be instantiated in scripts) * change the behavior of WindowProxy instances when it comes to doing things that would commit them to eternal invariants to throw instead of forwarding. This solution may still be possible, because it's unlikely that Object.defineProperty is widely used in web content today. But this change should happen pretty fast before content relies on it. David [1] http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0188.html [2] http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0266.html [3] http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0267.html [4] http://davidbruant.github.com/iframeProxyIssueDemo/ [5] https://github.com/DavidBruant/iframeProxyIssueDemo/blob/master/index.html [6] https://mail.mozilla.org/pipermail/es-discuss/2012-September/025243.html [7] https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.com wrote: A good question by Anne van Kesteren [1] followed by good remarks by Boris Zbarsky [2][3] made me try a little something [4][5]. The WindowProxy object returned as the 'contentWindow' property of iframes never changes; whatever you do when changing the @src, always the same object is returned. However, based on whether the @src is changed, the WindowProxy proxies to a different Window instance. I bumped into this myself just recently while attempting to implement virtualized navigable iframes in Caja — I need to emulate exactly this behavior. [...] I wish to point out that apparently iframe.contentWindow does break quite a lot of eternal invariants [7] which isn't really good news, because it questions their eternity. Indeed! Among alternatives I'm thinking of: * define a new type of proxies for which the target can be changed (either only as a spec device of as an actual object that can be instantiated in scripts) * change the behavior of WindowProxy instances when it comes to doing things that would commit them to eternal invariants to throw instead of forwarding. This solution may still be possible, because it's unlikely that Object.defineProperty is widely used in web content today. But this change should happen pretty fast before content relies on it. The best option I see at the moment would be that a WindowProxy refuses to commit, but a Window does. That is, code operating on 'window' within the iframe can still Object.defineProperty, but from the outside every property of Window appears to be configurable. This is what I have implemented in my current draft. On the other hand, it seems that in browsers either 'window' is also the same (!) proxy, or === invariants are broken, or the WindowProxy is acting as a membrane: f.contentWindow === f.contentWindow.window true This would seem to prohibit the distinction I propose. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
This can be handled by proxies and in fact it's something I've done with proxies for App.js for pretty much the same scenario. A single Window object exists for each desktop window created, but the page can be navigated as it does in a browser, wiping out the entire context's object graph. The proxy simply reestablishes a connection with the new JS context upon navigating and changes targets. All the object references to objects from the old JS context (which forms a membrane, as they are all proxies) are neutered at the same time. The specified proxy target doesn't correspond to the various context globals; rather it can be used to house expando properties that may be shown on every transitory target object. https://github.com/appjs/appjs/blob/master/lib/window.js#L35 On Wed, Dec 12, 2012 at 2:19 PM, David Bruant bruan...@gmail.com wrote: Hi, A good question by Anne van Kesteren [1] followed by good remarks by Boris Zbarsky [2][3] made me try a little something [4][5]. The WindowProxy object returned as the 'contentWindow' property of iframes never changes; whatever you do when changing the @src, always the same object is returned. However, based on whether the @src is changed, the WindowProxy proxies to a different Window instance. I thing this is something that can't be implemented with direct proxies. Is this conclusion shared? Assuming I'm not wrong in my analysis, now is time to wonder if the direct proxy design should be change to make this part writable in JavaScript. If self-hosting the browser APIs as pure ECMAScript 6 is a goal, something needs to be changed indeed. If it's possible to relax this use case a little bit, following the direct proxies model described some time ago [6], it would be possible to do the following: * Model WindowProxy objects as ES proxies * Allow the UA to change the target of this proxy at will (which is very close to what's actually done and spec'ed anyway) I wish to point out that apparently iframe.contentWindow does break quite a lot of eternal invariants [7] which isn't really good news, because it questions their eternity. Among alternatives I'm thinking of: * define a new type of proxies for which the target can be changed (either only as a spec device of as an actual object that can be instantiated in scripts) * change the behavior of WindowProxy instances when it comes to doing things that would commit them to eternal invariants to throw instead of forwarding. This solution may still be possible, because it's unlikely that Object.defineProperty is widely used in web content today. But this change should happen pretty fast before content relies on it. David [1] http://lists.w3.org/Archives/**Public/public-script-coord/** 2012OctDec/0188.htmlhttp://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0188.html [2] http://lists.w3.org/Archives/**Public/public-script-coord/** 2012OctDec/0266.htmlhttp://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0266.html [3] http://lists.w3.org/Archives/**Public/public-script-coord/** 2012OctDec/0267.htmlhttp://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0267.html [4] http://davidbruant.github.com/**iframeProxyIssueDemo/http://davidbruant.github.com/iframeProxyIssueDemo/ [5] https://github.com/**DavidBruant/**iframeProxyIssueDemo/blob/** master/index.htmlhttps://github.com/DavidBruant/iframeProxyIssueDemo/blob/master/index.html [6] https://mail.mozilla.org/**pipermail/es-discuss/2012-** September/025243.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2012-September/025243.html [7] https://mail.mozilla.org/**pipermail/es-discuss/2011-May/**014150.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 12/12/2012 20:29, Kevin Reid a écrit : On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: A good question by Anne van Kesteren [1] followed by good remarks by Boris Zbarsky [2][3] made me try a little something [4][5]. The WindowProxy object returned as the 'contentWindow' property of iframes never changes; whatever you do when changing the @src, always the same object is returned. However, based on whether the @src is changed, the WindowProxy proxies to a different Window instance. I bumped into this myself just recently while attempting to implement virtualized navigable iframes in Caja — I need to emulate exactly this behavior. Do you have a pointer to the code for that, just out of curiosity? [...] I wish to point out that apparently iframe.contentWindow does break quite a lot of eternal invariants [7] which isn't really good news, because it questions their eternity. Indeed! Among alternatives I'm thinking of: * define a new type of proxies for which the target can be changed (either only as a spec device of as an actual object that can be instantiated in scripts) * change the behavior of WindowProxy instances when it comes to doing things that would commit them to eternal invariants to throw instead of forwarding. This solution may still be possible, because it's unlikely that Object.defineProperty is widely used in web content today. But this change should happen pretty fast before content relies on it. The best option I see at the moment would be that a WindowProxy refuses to commit, but a Window does. That is, code operating on 'window' within the iframe can still Object.defineProperty, but from the outside every property of Window appears to be configurable. This is what I have implemented in my current draft. Let's say that the window has a non-configurable, non-writable property, what happens to Object.getOwnPropertyDescriptor on the WindowProxy? Does it throw? (I would be fine with this behavior, but I'm just wondering) On the other hand, it seems that in browsers either 'window' is also the same (!) proxy, or === invariants are broken, or the WindowProxy is acting as a membrane: f.contentWindow === f.contentWindow.window true I think it's a membrane. The HTML5 spec [1] makes pretty clear that the window property isn't a Window, but a WindowProxy. HTML5 experts will know better, but I think no one ever manipulates directly a Window instance, there is always a WindowProxy mediating the access. Of course, the implementation is free to optimize this mediation. David [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Window interceptors (as we call them in the browser world) are simply nuts.
We simply shouldn't be terribly interested in re-creating this wart.
On Wednesday, December 12, 2012, David Bruant wrote:
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant
bruan...@gmail.comjavascript:_e({}, 'cvml', 'bruan...@gmail.com');
wrote:
A good question by Anne van Kesteren [1] followed by good remarks by
Boris Zbarsky [2][3] made me try a little something [4][5].
The WindowProxy object returned as the 'contentWindow' property of
iframes never changes; whatever you do when changing the @src, always the
same object is returned. However, based on whether the @src is changed, the
WindowProxy proxies to a different Window instance.
I bumped into this myself just recently while attempting to implement
virtualized navigable iframes in Caja — I need to emulate exactly this
behavior.
Do you have a pointer to the code for that, just out of curiosity?
[...] I wish to point out that apparently iframe.contentWindow does break
quite a lot of eternal invariants [7] which isn't really good news,
because it questions their eternity.
Indeed!
Among alternatives I'm thinking of:
* define a new type of proxies for which the target can be changed
(either only as a spec device of as an actual object that can be
instantiated in scripts)
* change the behavior of WindowProxy instances when it comes to doing
things that would commit them to eternal invariants to throw instead of
forwarding. This solution may still be possible, because it's unlikely that
Object.defineProperty is widely used in web content today. But this change
should happen pretty fast before content relies on it.
The best option I see at the moment would be that a WindowProxy refuses
to commit, but a Window does. That is, code operating on 'window' within
the iframe can still Object.defineProperty, but from the outside every
property of Window appears to be configurable. This is what I have
implemented in my current draft.
Let's say that the window has a non-configurable, non-writable property,
what happens to Object.getOwnPropertyDescriptor on the WindowProxy? Does it
throw? (I would be fine with this behavior, but I'm just wondering)
On the other hand, it seems that in browsers either 'window' is also
the same (!) proxy, or === invariants are broken, or the WindowProxy is
acting as a membrane:
f.contentWindow === f.contentWindow.window
true
I think it's a membrane. The HTML5 spec [1] makes pretty clear that the
window property isn't a Window, but a WindowProxy.
HTML5 experts will know better, but I think no one ever manipulates
directly a Window instance, there is always a WindowProxy mediating the
access. Of course, the implementation is free to optimize this mediation.
David
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
With the previous proxy design indeed. I see you're using Proxy.create [1] But it won't be possible to do this with the new design, because of invariant enforcement. I recommend staying away from Proxy.create as it's likely to not appear in the spec and be removed from implementations. David [1] https://github.com/appjs/appjs/blob/master/lib/handlers.js#L21 Le 12/12/2012 20:30, Brandon Benvie a écrit : This can be handled by proxies and in fact it's something I've done with proxies for App.js for pretty much the same scenario. A single Window object exists for each desktop window created, but the page can be navigated as it does in a browser, wiping out the entire context's object graph. The proxy simply reestablishes a connection with the new JS context upon navigating and changes targets. All the object references to objects from the old JS context (which forms a membrane, as they are all proxies) are neutered at the same time. The specified proxy target doesn't correspond to the various context globals; rather it can be used to house expando properties that may be shown on every transitory target object. https://github.com/appjs/appjs/blob/master/lib/window.js#L35 On Wed, Dec 12, 2012 at 2:19 PM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Hi, A good question by Anne van Kesteren [1] followed by good remarks by Boris Zbarsky [2][3] made me try a little something [4][5]. The WindowProxy object returned as the 'contentWindow' property of iframes never changes; whatever you do when changing the @src, always the same object is returned. However, based on whether the @src is changed, the WindowProxy proxies to a different Window instance. I thing this is something that can't be implemented with direct proxies. Is this conclusion shared? Assuming I'm not wrong in my analysis, now is time to wonder if the direct proxy design should be change to make this part writable in JavaScript. If self-hosting the browser APIs as pure ECMAScript 6 is a goal, something needs to be changed indeed. If it's possible to relax this use case a little bit, following the direct proxies model described some time ago [6], it would be possible to do the following: * Model WindowProxy objects as ES proxies * Allow the UA to change the target of this proxy at will (which is very close to what's actually done and spec'ed anyway) I wish to point out that apparently iframe.contentWindow does break quite a lot of eternal invariants [7] which isn't really good news, because it questions their eternity. Among alternatives I'm thinking of: * define a new type of proxies for which the target can be changed (either only as a spec device of as an actual object that can be instantiated in scripts) * change the behavior of WindowProxy instances when it comes to doing things that would commit them to eternal invariants to throw instead of forwarding. This solution may still be possible, because it's unlikely that Object.defineProperty is widely used in web content today. But this change should happen pretty fast before content relies on it. David [1] http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0188.html [2] http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0266.html [3] http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0267.html [4] http://davidbruant.github.com/iframeProxyIssueDemo/ [5] https://github.com/DavidBruant/iframeProxyIssueDemo/blob/master/index.html [6] https://mail.mozilla.org/pipermail/es-discuss/2012-September/025243.html [7] https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html ___ es-discuss mailing list es-discuss@mozilla.org mailto: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: A DOM use case that can't be emulated with direct proxies
On Wed, Dec 12, 2012 at 11:39 AM, David Bruant bruan...@gmail.com wrote: Le 12/12/2012 20:29, Kevin Reid a écrit : On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.comwrote: The WindowProxy object returned as the 'contentWindow' property of iframes never changes; whatever you do when changing the @src, always the same object is returned. However, based on whether the @src is changed, the WindowProxy proxies to a different Window instance. I bumped into this myself just recently while attempting to implement virtualized navigable iframes in Caja — I need to emulate exactly this behavior. Do you have a pointer to the code for that, just out of curiosity? I haven't made it public yet, but it's just the obvious implementation of an (old-style, as implemented in Firefox/Chrome) proxy with a switchable “target”. The best option I see at the moment would be that a WindowProxy refuses to commit, but a Window does. That is, code operating on 'window' within the iframe can still Object.defineProperty, but from the outside every property of Window appears to be configurable. This is what I have implemented in my current draft. Let's say that the window has a non-configurable, non-writable property, what happens to Object.getOwnPropertyDescriptor on the WindowProxy? Does it throw? (I would be fine with this behavior, but I'm just wondering) It returns a descriptor which is identical except that it claims to be configurable. Attempting to actually reconfigure it using defineProperty would throw. On the other hand, it seems that in browsers either 'window' is also the same (!) proxy, or === invariants are broken, or the WindowProxy is acting as a membrane: f.contentWindow === f.contentWindow.window true I think it's a membrane. The HTML5 spec [1] makes pretty clear that the window property isn't a Window, but a WindowProxy. HTML5 experts will know better, but I think no one ever manipulates directly a Window instance, there is always a WindowProxy mediating the access. Of course, the implementation is free to optimize this mediation. The disturbing thing about window instanceof WindowProxy, if you will, (given that it accurately reports its mutability) is that since window is the global environment, it means that the global environment cannot have immutable things. Of course, SES actually establishes a new environment (using 'with') for secured eval. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 12/12/2012 20:44, Alex Russell a écrit :
Window interceptors (as we call them in the browser world) are simply
nuts. We simply shouldn't be terribly interested in re-creating this wart.
I'm not sure I understand your point. Do you mean that emulating them in
pure ECMAScript should be an exception to the emulate DOM proxy use case?
David
On Wednesday, December 12, 2012, David Bruant wrote:
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant
bruan...@gmail.com javascript:_e({}, 'cvml',
'bruan...@gmail.com'); wrote:
A good question by Anne van Kesteren [1] followed by good
remarks by Boris Zbarsky [2][3] made me try a little
something [4][5].
The WindowProxy object returned as the 'contentWindow'
property of iframes never changes; whatever you do when
changing the @src, always the same object is returned.
However, based on whether the @src is changed, the
WindowProxy proxies to a different Window instance.
I bumped into this myself just recently while attempting to
implement virtualized navigable iframes in Caja — I need to
emulate exactly this behavior.
Do you have a pointer to the code for that, just out of curiosity?
[...] I wish to point out that apparently
iframe.contentWindow does break quite a lot of eternal
invariants [7] which isn't really good news, because it
questions their eternity.
Indeed!
Among alternatives I'm thinking of:
* define a new type of proxies for which the target can be
changed (either only as a spec device of as an actual object
that can be instantiated in scripts)
* change the behavior of WindowProxy instances when it comes
to doing things that would commit them to eternal invariants
to throw instead of forwarding. This solution may still be
possible, because it's unlikely that Object.defineProperty is
widely used in web content today. But this change should
happen pretty fast before content relies on it.
The best option I see at the moment would be that a WindowProxy
refuses to commit, but a Window does. That is, code operating on
'window' within the iframe can still Object.defineProperty, but
from the outside every property of Window appears to be
configurable. This is what I have implemented in my current draft.
Let's say that the window has a non-configurable, non-writable
property, what happens to Object.getOwnPropertyDescriptor on the
WindowProxy? Does it throw? (I would be fine with this behavior,
but I'm just wondering)
On the other hand, it seems that in browsers either 'window' is
also the same (!) proxy, or === invariants are broken, or the
WindowProxy is acting as a membrane:
f.contentWindow === f.contentWindow.window
true
I think it's a membrane. The HTML5 spec [1] makes pretty clear
that the window property isn't a Window, but a WindowProxy.
HTML5 experts will know better, but I think no one ever
manipulates directly a Window instance, there is always a
WindowProxy mediating the access. Of course, the implementation is
free to optimize this mediation.
David
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Yep. On Wednesday, December 12, 2012, David Bruant wrote: Le 12/12/2012 20:44, Alex Russell a écrit : Window interceptors (as we call them in the browser world) are simply nuts. We simply shouldn't be terribly interested in re-creating this wart. I'm not sure I understand your point. Do you mean that emulating them in pure ECMAScript should be an exception to the emulate DOM proxy use case? David On Wednesday, December 12, 2012, David Bruant wrote: Le 12/12/2012 20:29, Kevin Reid a écrit : On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.comwrote: A good question by Anne van Kesteren [1] followed by good remarks by Boris Zbarsky [2][3] made me try a little something [4][5]. The WindowProxy object returned as the 'contentWindow' property of iframes never changes; whatever you do when changing the @src, always the same object is returned. However, based on whether the @src is changed, the WindowProxy proxies to a different Window instance. I bumped into this myself just recently while attempting to implement virtualized navigable iframes in Caja — I need to emulate exactly this behavior. Do you have a pointer to the code for that, just out of curiosity? [...] I wish to point out that apparently iframe.contentWindow does break quite a lot of eternal invariants [7] which isn't really good news, because it questions their eternity. Indeed! Among alternatives I'm thinking of: * define a new type of proxies for which the target can be changed (either only as a spec device of as an actual object that can be instantiated in scripts) * change the behavior of WindowProxy instances when it comes to doing things that would commit them to eternal invariants to throw instead of forwarding. This solution may still be possible, because it's unlikely that Object.defineProperty is widely used in web content today. But this change should happen pretty fast before content relies on it. The best option I see at the moment would be that a WindowProxy refuses to commit, but a Window does. That is, code operating on ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 12/12/2012 20:49, Kevin Reid a écrit : On Wed, Dec 12, 2012 at 11:39 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 12/12/2012 20:29, Kevin Reid a écrit : On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: The WindowProxy object returned as the 'contentWindow' property of iframes never changes; whatever you do when changing the @src, always the same object is returned. However, based on whether the @src is changed, the WindowProxy proxies to a different Window instance. I bumped into this myself just recently while attempting to implement virtualized navigable iframes in Caja — I need to emulate exactly this behavior. Do you have a pointer to the code for that, just out of curiosity? I haven't made it public yet, but it's just the obvious implementation of an (old-style, as implemented in Firefox/Chrome) proxy with a switchable “target”. Interesting. As I said, target-switching won't be possible in direct proxies. The best option I see at the moment would be that a WindowProxy refuses to commit, but a Window does. That is, code operating on 'window' within the iframe can still Object.defineProperty, but from the outside every property of Window appears to be configurable. This is what I have implemented in my current draft. Let's say that the window has a non-configurable, non-writable property, what happens to Object.getOwnPropertyDescriptor on the WindowProxy? Does it throw? (I would be fine with this behavior, but I'm just wondering) It returns a descriptor which is identical except that it claims to be configurable. Direct proxies invariant checks would make such a lie about configurability impossible. The engine would throw if you try to pretend a non-configurable property is configurable. See http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies#invariant_enforcement Attempting to actually reconfigure it using defineProperty would throw. On the other hand, it seems that in browsers either 'window' is also the same (!) proxy, or === invariants are broken, or the WindowProxy is acting as a membrane: f.contentWindow === f.contentWindow.window true I think it's a membrane. The HTML5 spec [1] makes pretty clear that the window property isn't a Window, but a WindowProxy. HTML5 experts will know better, but I think no one ever manipulates directly a Window instance, there is always a WindowProxy mediating the access. Of course, the implementation is free to optimize this mediation. The disturbing thing about window instanceof WindowProxy, if you will, (given that it accurately reports its mutability) is that since window is the global environment, it means that the global environment cannot have immutable things. Of course, SES actually establishes a new environment (using 'with') for secured eval. One idea would be that different handlers are used based on the context. Different handlers would encode whether to create non-configurable properties. If the WindowProxy instance has been obtained through accessing the global of your environement, you can add non-configurable properties. If the WindowProxy has been obtained with iframe.contentWindow then you can't create non-configurable properties. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Wed, Dec 12, 2012 at 12:03 PM, David Bruant bruan...@gmail.com wrote: Le 12/12/2012 20:49, Kevin Reid a écrit : I haven't made it public yet, but it's just the obvious implementation of an (old-style, as implemented in Firefox/Chrome) proxy with a switchable “target”. Interesting. As I said, target-switching won't be possible in direct proxies. I understand that direct proxies have an internal “target” object. Will it not be possible to simply never place any properties on said object (thus not constrain future behavior) while still appearing to have properties? This text suggests that is a possible and expected pattern: Since this Proxy API requires one to pass an existing object as a target to wrap, it may seem that this API precludes the creation of fully “virtual” objects that are not represented by an existing JSObject. It’s easy to create such “virtual” proxies: just pass a fresh empty object as the target to Proxy and implement all the handler traps so that none of them defaults to forwarding, or otherwise touches thetarget. In my case there is an actual object, of course, but I implement forwarding to said object myself; the JS implementation never knows that I am “treating it as a target”. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Alex Russell wrote:
Window interceptors (as we call them in the browser world) are simply
nuts. We simply shouldn't be terribly interested in re-creating this wart.
Having a stable object identity for the window proxy, while navigating
the window through a series of page loads, requires this wart or an
equivalent one. Browsers came to this design the hard way. Without the
window proxy, with only one global object exposed (not just on the scope
chain), insecurity or else inefficiency ensues.
You could say the wart is having a stable object identity for an object
that proxies to more than one object over time (but not two at the same
time).
That is plausible, except that this use-case looks a lot like a membrane
use-case. Is there anything in the membrane literature where the
membrane wraps different objects over its lifetime?
/be
On Wednesday, December 12, 2012, David Bruant wrote:
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant
bruan...@gmail.com javascript:_e({}, 'cvml',
'bruan...@gmail.com'); wrote:
A good question by Anne van Kesteren [1] followed by good
remarks by Boris Zbarsky [2][3] made me try a little
something [4][5].
The WindowProxy object returned as the 'contentWindow'
property of iframes never changes; whatever you do when
changing the @src, always the same object is returned.
However, based on whether the @src is changed, the
WindowProxy proxies to a different Window instance.
I bumped into this myself just recently while attempting to
implement virtualized navigable iframes in Caja — I need to
emulate exactly this behavior.
Do you have a pointer to the code for that, just out of curiosity?
[...] I wish to point out that apparently
iframe.contentWindow does break quite a lot of eternal
invariants [7] which isn't really good news, because it
questions their eternity.
Indeed!
Among alternatives I'm thinking of:
* define a new type of proxies for which the target can be
changed (either only as a spec device of as an actual object
that can be instantiated in scripts)
* change the behavior of WindowProxy instances when it comes
to doing things that would commit them to eternal invariants
to throw instead of forwarding. This solution may still be
possible, because it's unlikely that Object.defineProperty is
widely used in web content today. But this change should
happen pretty fast before content relies on it.
The best option I see at the moment would be that a WindowProxy
refuses to commit, but a Window does. That is, code operating on
'window' within the iframe can still Object.defineProperty, but
from the outside every property of Window appears to be
configurable. This is what I have implemented in my current draft.
Let's say that the window has a non-configurable, non-writable
property, what happens to Object.getOwnPropertyDescriptor on the
WindowProxy? Does it throw? (I would be fine with this behavior,
but I'm just wondering)
On the other hand, it seems that in browsers either 'window' is
also the same (!) proxy, or === invariants are broken, or the
WindowProxy is acting as a membrane:
f.contentWindow === f.contentWindow.window
true
I think it's a membrane. The HTML5 spec [1] makes pretty clear
that the window property isn't a Window, but a WindowProxy.
HTML5 experts will know better, but I think no one ever
manipulates directly a Window instance, there is always a
WindowProxy mediating the access. Of course, the implementation is
free to optimize this mediation.
David
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object
___
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: A DOM use case that can't be emulated with direct proxies
Le 12/12/2012 21:09, Kevin Reid a écrit : On Wed, Dec 12, 2012 at 12:03 PM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 12/12/2012 20:49, Kevin Reid a écrit : I haven't made it public yet, but it's just the obvious implementation of an (old-style, as implemented in Firefox/Chrome) proxy with a switchable “target”. Interesting. As I said, target-switching won't be possible in direct proxies. I understand that direct proxies have an internal “target” object. Will it not be possible to simply never place any properties on said object (thus not constrain future behavior) while still appearing to have properties? This text suggests that is a possible and expected pattern: Since this Proxy API requires one to pass an existing object as a |target| to wrap, it may seem that this API precludes the creation of fully “virtual” objects that are not represented by an existing JSObject. It’s easy to create such “virtual” proxies: just pass a fresh empty object as the target to |Proxy| and implement all the handler traps so that none of them defaults to forwarding, or otherwise touches the|target|. In my case there is an actual object, of course, but I implement forwarding to said object myself; the JS implementation never knows that I am “treating it as a target”. I was a bit too strong in my statement, sorry. Let me rephrase: the internal [[Target]] can't be changed, but a proxy can emulate changing of fake target as long as what happens with this fake target doesn't involve invariant checking. That's the reason I was suggesting that WindowProxies could (maybe depending on how the object reference was obtained) throw whenever invariant checks are involved. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Wed, Dec 12, 2012 at 12:35 PM, David Bruant bruan...@gmail.com wrote: I was a bit too strong in my statement, sorry. Let me rephrase: the internal [[Target]] can't be changed, but a proxy can emulate changing of fake target as long as what happens with this fake target doesn't involve invariant checking. That's the reason I was suggesting that WindowProxies could (maybe depending on how the object reference was obtained) throw whenever invariant checks are involved. Exactly. So a user-defined switching proxy needs only to: 1. refuse to commit to any invariant (non-configurable property or preventExtensions) 2. even if its switchable-target has an invariant, do not expose that invariant (i.e. pretend each property is configurable) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
This use case is much more strongly aligned with the purely virtual object than it is for the forwarded one, despite the goal being to wrap real objects. Doing fancy things with object identity requires it. On Wed, Dec 12, 2012 at 3:42 PM, Kevin Reid kpr...@google.com wrote: On Wed, Dec 12, 2012 at 12:35 PM, David Bruant bruan...@gmail.com wrote: I was a bit too strong in my statement, sorry. Let me rephrase: the internal [[Target]] can't be changed, but a proxy can emulate changing of fake target as long as what happens with this fake target doesn't involve invariant checking. That's the reason I was suggesting that WindowProxies could (maybe depending on how the object reference was obtained) throw whenever invariant checks are involved. Exactly. So a user-defined switching proxy needs only to: 1. refuse to commit to any invariant (non-configurable property or preventExtensions) 2. even if its switchable-target has an invariant, do not expose that invariant (i.e. pretend each property is configurable) ___ 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: A DOM use case that can't be emulated with direct proxies
Le 12/12/2012 21:42, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 12:35 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
I was a bit too strong in my statement, sorry. Let me rephrase:
the internal [[Target]] can't be changed, but a proxy can emulate
changing of fake target as long as what happens with this fake
target doesn't involve invariant checking.
That's the reason I was suggesting that WindowProxies could (maybe
depending on how the object reference was obtained) throw whenever
invariant checks are involved.
Exactly. So a user-defined switching proxy needs only to:
1. refuse to commit to any invariant (non-configurable property or
preventExtensions)
2. even if its switchable-target has an invariant, do not expose that
invariant (i.e. pretend each property is configurable)
Pretend that something non-configurable actually is configurable is an
invariant violation. To be more concrete:
* There is an webpage with an iframe
* The same window object is proxied by 2 WindowProxy instances. One
outside the iframe, one inside.
* Inside of the iframe, scripts can add a non-configurable property
azerty to their global.
* Outside the iframe, what happens when
Object.getOwnPropertyDescriptor(iframeWindow, 'azerty') is called?
You're suggesting that {configurable: true} is returned. The problem is
that on the actual Window instance, there is a non-configurable
property, so if the WindowProxy handler tries to do that, an error will
be thrown because of invariant checks.
I think throwing is the correct behavior here. The handler can't tell
the truth about non-configurable properties (because a later different
target may not have the same non-configurable properties), but also
can't lie, because lies involves throwing... well, since I say that
throwing is the correct behavior, I guess lying is too in a way.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Wed, Dec 12, 2012 at 1:23 PM, David Bruant bruan...@gmail.com wrote:
Le 12/12/2012 21:42, Kevin Reid a écrit :
Exactly. So a user-defined switching proxy needs only to:
1. refuse to commit to any invariant (non-configurable property or
preventExtensions)
2. even if its switchable-target has an invariant, do not expose that
invariant (i.e. pretend each property is configurable)
Pretend that something non-configurable actually is configurable is an
invariant violation. To be more concrete:
* There is an webpage with an iframe
* The same window object is proxied by 2 WindowProxy instances. One
outside the iframe, one inside.
* Inside of the iframe, scripts can add a non-configurable property
azerty to their global.
* Outside the iframe, what happens when
Object.getOwnPropertyDescriptor(iframeWindow, 'azerty') is called?
You're suggesting that {configurable: true} is returned. The problem is
that on the actual Window instance, there is a non-configurable property,
so if the WindowProxy handler tries to do that, an error will be thrown
because of invariant checks.
The JS runtime won't know that the proxy has anything to do with the actual
Window instance. The Proxy's formal target will be just {}; only the
handler interacts with the Window. This is the distinction I meant but did
not state clearly by saying “switchable-target” as opposed to proxy-target.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 12/12/2012 22:30, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 1:23 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/12/2012 21:42, Kevin Reid a écrit :
Exactly. So a user-defined switching proxy needs only to:
1. refuse to commit to any invariant (non-configurable property
or preventExtensions)
2. even if its switchable-target has an invariant, do not expose
that invariant (i.e. pretend each property is configurable)
Pretend that something non-configurable actually is configurable
is an invariant violation. To be more concrete:
* There is an webpage with an iframe
* The same window object is proxied by 2 WindowProxy instances.
One outside the iframe, one inside.
* Inside of the iframe, scripts can add a non-configurable
property azerty to their global.
* Outside the iframe, what happens when
Object.getOwnPropertyDescriptor(iframeWindow, 'azerty') is called?
You're suggesting that {configurable: true} is returned. The
problem is that on the actual Window instance, there is a
non-configurable property, so if the WindowProxy handler tries to
do that, an error will be thrown because of invariant checks.
The JS runtime won't know that the proxy has anything to do with the
actual Window instance. The Proxy's formal target will be just {};
This target, even if dummy, is the one that will be used for invariants
checks. You can't get away from this by design. This is one of the most
important part of the direct proxies design.
Even if you switch of fake target, the engine will still perform checks
on the dummy internal [[Target]].
I feel we're cycling in what we say and I feel I can't find the right
words to explain my point. One idea would be for you to implement a
target-switching proxy based on direct proxies (Firefox has them
natively or you can use Tom's shim [1]). I'm confident you'll understand
my point through this exercise.
David
[1] https://github.com/tvcutsem/harmony-reflect
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
The ability to break invariants of the language either requires an external object-capability provider to dole out permission to do this (such as what is currently done with chrome code being executed with access to privileged internals), or a mechanism in the language to dole out special permissions that goes beyond first come, first serve. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Brandon Benvie wrote: The ability to break invariants of the language either requires an external object-capability provider to dole out permission to do this (such as what is currently done with chrome code Just to clarify for anyone following along (including me!), you must mean Firefox or another XUL app's UI chrome including privileged JS, which indeed is endowed with extra capabilities. Not Google Chrome -- right? /be being executed with access to privileged internals), or a mechanism in the language to dole out special permissions that goes beyond first come, first serve. ___ 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: A DOM use case that can't be emulated with direct proxies
Yeah I was using it in the Mozilla terminology way, not referring to the browser. =D On Wed, Dec 12, 2012 at 6:16 PM, Brendan Eich bren...@mozilla.org wrote: Brandon Benvie wrote: The ability to break invariants of the language either requires an external object-capability provider to dole out permission to do this (such as what is currently done with chrome code Just to clarify for anyone following along (including me!), you must mean Firefox or another XUL app's UI chrome including privileged JS, which indeed is endowed with extra capabilities. Not Google Chrome -- right? /be being executed with access to privileged internals), or a mechanism in the language to dole out special permissions that goes beyond first come, first serve. __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
