From: Mark S. Miller [mailto:erig...@google.com]
On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky bzbar...@mit.edu wrote:
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
On Wed, Jan 28, 2015 at 8:51 AM, Domenic Denicola d...@domenic.me wrote:
From: Mark S. Miller [mailto:erig...@google.com]
On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I'd like to understand better the suggestion here, because I'm not sure
I'm entirely following
On Wed, Jan 28, 2015 at 11:08 AM, Domenic Denicola d...@domenic.me wrote:
From: Mark S. Miller [mailto:erig...@google.com]
In this situation, it will try and succeed. This more closely obeys the
intent in the original code (e.g., the comment in the jQuery code), since
it creates a
From: Mark S. Miller [mailto:erig...@google.com]
In this situation, it will try and succeed. This more closely obeys the
intent in the original code (e.g., the comment in the jQuery code), since it
creates a non-configurable property on the *Window* W. It does not violate
any invariant,
Mark S. Miller wrote:
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:
On 12/4/14 11:49 AM, Mark S. Miller wrote:
On Thu, Dec 4, 2014 at 2:58 AM, Boris Zbarsky bzbar...@mit.edu wrote:
OK. What do we do if we discover that throwing from the defineProperty call
with a non-configurable property descriptor is not web-compatible?
What we always do
So just for the
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
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
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
On Tue, Jan 27, 2015 at 9:45 PM, Mark S. Miller erig...@google.com wrote:
On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/27/15 4:44 PM, Mark S. Miller wrote:
Since the WindowProxy is not a Proxy, or more relevantly, even if it
were a Proxy, the underlying
On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/27/15 4:44 PM, Mark S. Miller wrote:
Since the WindowProxy is not a Proxy, or more relevantly, even if it
were a Proxy, the underlying Window is not its target, we can even do
the following:
When the WindowProxy
On Tue, Jan 27, 2015 at 7:22 PM, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
The reason why the intent is unwarranted is that the descriptor omits
configurable: rather than explicitly saying configurable: true. If the
owner object already has a configurable own property of
On 1/15/15 1:22 PM, Ian Hickson wrote:
It's what IE does, according to Travis.
I'll let Travis address this.
Care to ask the UA implementors who are clearly not doing anything even
resembling your spec? Because it might turn out they might have reasons
for it...
I've asked you many times.
On Thu, 15 Jan 2015, Boris Zbarsky wrote:
It doesn't match _all_ implementations, certainly.
OK, but have you bothered to find out why?
The usual reason is just that there was no spec initially, and that the
relevant implementations haven't bothered to fix it since the spec was
written.
On Thu, 4 Dec 2014, Boris Zbarsky wrote:
On 12/4/14, 1:36 PM, Travis Leithead wrote:
In IE's implementation, the window proxy has no storage as a typical
JS var--it's only a semi-intelligent forwarder to its companion
inner window.
That's an IE implementation detail.
It's more than
From: Travis Leithead [mailto:travis.leith...@microsoft.com]
WindowProxies are going to be a challenge when it comes to a pure ES
implementation.
Shouldn't be too hard to implement a Direct Proxy that follows this proto-spec:
https://github.com/domenic/window-proxy-spec
On 1/14/15 5:58 PM, Travis Leithead wrote:
The other challenge that just came to mind, is the
document object—at least in Gecko and IE: a document.write call will
“re-init” the object (subbing out the old var for a new one)
What Gecko does on document.open is just create a new Window, just
On 1/14/15 3:17 PM, Ian Hickson wrote:
It's more than that. It's how the HTML spec defines WindowProxy.
The point is, the HTML spec's definition is not expressible in ES terms.
So how do go about bridging this gap?
According to the HTML spec, all operations that would be performed on the
On Wed, 14 Jan 2015, Boris Zbarsky wrote:
On 1/14/15 3:17 PM, Ian Hickson wrote:
It's more than that. It's how the HTML spec defines WindowProxy.
The point is, the HTML spec's definition is not expressible in ES terms.
So how do go about bridging this gap?
I don't understand what you
Hi Travis, I didn't follow. Could you expand, assuming less background
knowledge? Thanks.
On Jan 14, 2015 2:58 PM, Travis Leithead travis.leith...@microsoft.com
wrote:
WindowProxies are going to be a challenge when it comes to a pure ES
implementation. The other challenge that just came to
On 1/14/15 7:40 PM, Ian Hickson wrote:
I don't understand what you mean by expressible in ES terms.
The behavior of ES objects is expressed in terms of various internal
methods. That's what you have to do to express what an ES object does.
No. WindowProxy isn't an ES Proxy.
It's an ES
Boris has this exactly right. Further, a malicious proxy handler can
leverage the presence of a single object that violates these invariants
into the creation of arbitrary other proxies objects that also violate
these invariants. The key is that the enforcement of the invariants relies
on the
bz said:
ES also allows other exotic objects that define some other behavior
for those internal methods, but requires that the invariants be
preserved.
Hixie said:
So one option would be to just say that WindowProxy is not an ES object.
---
If it's available to JavaScript consumers it must
On 1/14/15 8:56 PM, Bjoern Hoehrmann wrote:
What are the odds that the behavior observable by web pages can actually
be defined sanely such that ES invariants and compatibility requirements
are satisfied?
My personal best estimate is about 30% chance for the one such
definition we have so far
On Jan 14, 2015, at 7:14 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 14 Jan 2015, Boris Zbarsky wrote:
The behavior of ES objects is expressed in terms of various internal methods.
That's what you have to do to express what an ES object does.
Not necessarily. We can also just say
On 1/14/15 10:14 PM, Ian Hickson wrote:
You are dismissing what I'm describing as being a misunderstanding of how
things should be considered to work,
No, I'm dismissing it as introducing magic that doesn't need to be
introduced and hence making the platform more complicate than it needs
to
Thanks. It is great to accumulate such retreats in case we need them.
However, it is also good to remember that, should we run into problems,
that experience will give us specific data that we might not have been able
to anticipate. The least painful retreat may very well take that specific
data
* Boris Zbarsky wrote:
You say every WindowProxy, but in practice in an ES implementation you
have some object, it has some internal methods. This is the last time
I'm bothering to go through this with you, since clearly we're getting
nowhere, as I said in
On 1/14/15 8:49 PM, Travis Leithead wrote:
and existing elements and their document are disconnected from the
window, while a new document and the new elements created from parsing
are put in their place.
More precisely, the old elements are disconnected from the document, the
document is
On Wed, 14 Jan 2015, Boris Zbarsky wrote:
The behavior of ES objects is expressed in terms of various internal methods.
That's what you have to do to express what an ES object does.
Not necessarily. We can also just say WindowProxy is its own thing and
here is how it works.
No.
On 12/4/14 5: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?
Based on a nice long conversation Yehuda and I just had, if we end up
there and really want to preserve all
Domenic's https://github.com/domenic/window-proxy-spec seems headed in the
right direction. I suggest starting there.
Test proposals by self-hosting in ES6. Such self hosting would use direct
proxies *not* because the term proxy in WindowProxy has any historical
relation -- it does not -- but
On Wed, Jan 14, 2015 at 7:14 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 14 Jan 2015, Boris Zbarsky wrote:
The behavior of ES objects is expressed in terms of various internal
methods.
That's what you have to do to express what an ES object does.
Not necessarily. We can also just say
On 11/30/14, 6:12 PM, Mark S. Miller wrote:
On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Per spec ES6, it seems to me like attempting to define a non-configurable
property on a WindowProxy should throw and getting a property descriptor for
a non-configurable property
On Thu, Dec 4, 2014 at 2:58 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/30/14, 6:12 PM, Mark S. Miller wrote:
On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Per spec ES6, it seems to me like attempting to define a non-configurable
property on a WindowProxy should
On 12/4/14, 10:44 AM, Travis Leithead wrote:
So... this will prevent defining non-configurable properties on the global?
It will prevent using
Object.defineProperty(window, name, non-configurable-descriptor);
to define a property.
Note that window is not the global. It's a proxy whose
On 12/4/14, 1:36 PM, Travis Leithead wrote:
Note that window is not the global. It's a proxy whose target is the global.
Yes, but within a browser UA, there is no way to get a reference to the naked
global because all entry-points return window proxies ;-)
Well, no way from web script.
On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/4/14, 1:36 PM, Travis Leithead wrote:
Note that window is not the global. It's a proxy whose target is the
global.
Yes, but within a browser UA, there is no way to get a reference to the
naked global because all
On 12/4/14, 4:45 PM, Mark Miller wrote:
On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Sure, for a scope chain. Testcase at
https://web.mit.edu/bzbarsky/www/testcases/windowproxy/use-old-window-1.html
That page demands a client certificate. Is that intentional?
Er,
On Thu, Dec 4, 2014 at 4:49 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/4/14, 4:45 PM, Mark Miller wrote:
On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Sure, for a scope chain. Testcase at
On 1 December 2014 at 03:12, Mark S. Miller erig...@google.com wrote:
On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Per spec ES6, it seems to me like attempting to define a non-configurable
property on a WindowProxy should throw and getting a property descriptor for
a
Hi,
I feel like I've been in an equivalent discussion some time ago, so
taking the liberty to answer.
Le 02/12/2014 13:59, Andreas Rossberg a écrit :
On 1 December 2014 at 03:12, Mark S. Miller erig...@google.com wrote:
On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Le 02/12/2014 14:24, David Bruant a écrit :
Hi,
I feel like I've been in an equivalent discussion some time ago
The topic felt familiar :-p
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0322.html
David
___
es-discuss mailing
Yes. I was glad to find in that message a pointer back to
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027114.html
On Tue, Dec 2, 2014 at 5:36 AM, David Bruant bruan...@gmail.com wrote:
Le 02/12/2014 14:24, David Bruant a écrit :
Hi,
I feel like I've been in an equivalent
On 12/2/14, 4:59 AM, Andreas Rossberg wrote:
On 1 December 2014 at 03:12, Mark S. Miller erig...@google.com wrote:
On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Per spec ES6, it seems to me like attempting to define a non-configurable
property on a WindowProxy should
On 12/2/14, 5:24 AM, David Bruant wrote:
The handler can have access to the list all declared variable to know
which property should behave as if non-configurable.
That's not even needed. If the handler just passes configurable defines
on through to the target for a property declared via
[ccing public-script-coord because I'm not sure what list is best for
this; mostly I'm looking for feedback from other UA implementors.]
We really need to create an actual specification for WindowProxy. One
of the serious problems is what to do with non-configurable properties.
Consider
On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
[ccing public-script-coord because I'm not sure what list is best for this;
mostly I'm looking for feedback from other UA implementors.]
We really need to create an actual specification for WindowProxy. One of
the
On Sun, Nov 30, 2014 at 6:12 PM, Mark S. Miller erig...@google.com wrote:
[...]
Put another way, if this invariant is preserved by WindowProxy, then
Should be: is not preserved by or is violated by
anyone else seeking to create another object that violates this
invariant can create a Proxy
49 matches
Mail list logo
