On 8 January 2013 22:33, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jan 8, 2013 at 1:30 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
so you are saying that Object.observe() does not suffer these problems ? Or
is just much simpler than Proxies ? ( yeah, I know, I guess both
2013/1/11 Nathan Wall nathan.w...@live.com
I thought part of the goal in ES6 was striving to make the DOM emulable
(dare I say implementable?) in pure ES. If that's the case, the inability
of DOM objects to be proxied sounds like a big deal.
I think we are missing an important point in this
All good except it's impossible/not meant to recognize Proxies in JS world?
On Sat, Jan 12, 2013 at 7:46 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
2013/1/11 Nathan Wall nathan.w...@live.com
I thought part of the goal in ES6 was striving to make the DOM emulable
(dare I say
Nathan wrote:
Hey Tom, I think you missed my point. The point was that in David and Boris'
discussion they agreed that the DOM should throw if it is given a Proxy in
`appendChild`. That sounded to me like it presumed that the DOM had a magical
ability to distinguish between DOM objects and
and in both cases you would have ...
Proxy.isDOMProxy = function (node) {
try {
document.documentElement.appendChild(node);
document.documentElement.removeChild(node);
return false;
} catch(gotcha) {
return true;
}
};
that's why I have talked about inconsistencies all over
This is silly.
I can use the closure pattern to vend objects that do not satisfy the
internal constraints the DOM imposes on some of its objects. No proxies
in sight.
So why is the method you wrote named isDOMProxy and whatever in the
world does it have to do with Proxy?
/be
Andrea
Le 12/01/2013 21:58, Andrea Giammarchi a écrit :
that is a (quick/imperfect/asexample) way to detect a proxy while I
understand these should not be detectable.
{} and [] also return true to your test, but they're not proxies. You
cannot use an imperfect test to prove a point.
As I (and others
did you read anything I have been written in this thread or you have a
short memory ?
I am strongly recommending to throw an error the moment an object cannot be
proxied . I don't want to detect node and proxied node, I don't want DOM
node to be allowed to be the first argument of the Proxy.
I
Thank you for the thoughtful reply. You sufficiently answered many of my
concerns related to DOM, but I want to focus on the need for the
`unknownPrivateSymbol` trap.
David Bruant wrote:
Imagine the following scenario:
Untrusted code A is given access to a graph of objects through a
Le 12/01/2013 23:28, Andrea Giammarchi a écrit :
I don't want to detect node and proxied node
Why would you have to?
Currently, before calling .appendChild, do you write code that detects
that you're not trying to append a normal object or a date or an array?
I have personally never done such
hmm.. I just realized that B doesn't have direct access to O. So even if B does
have access to M, trying to get N from P[M] would expose N to the membrane.
So perhaps I don't understand your original dilemma?
(Forgive me if I'm making you repeat past discussions for my sake. It's not my
Le 12/01/2013 23:54, Nathan Wall a écrit :
David Bruant wrote:
Leaking the information that the node is actually a proxy is due to a
DOM API issue (which is way way too late to fix obviously).
If you want proxied node to go in the tree, you'll need to find an
answer to the issue Boris Zbarsky
David if you think about the most used library out there and the fact it
would like to threat not only DOM nodes but objects or arrays too, you
realize we might have a problem with a proxy in the wild that is wrapping a
DOM node, isn't it?
$(whatIsThis)
So this unable to recognize but able to
This isn't exactly a direct parallel because all the types that are
included as part of ES6 will be proxyable in such a way that the proxy can
be transparently interchanged with its target. The problem with DOM objects
is that this isn't true. I think it would be a good practice for the
providers
also because I believe it is straight forward ... is this a hosted thingy
? throw this object cannot be proxied
So the source of all evil disappear until Proxy is eventually able to wrap
DOM instances too.
On Sat, Jan 12, 2013 at 3:18 PM, Brandon Benvie
bran...@brandonbenvie.comwrote:
This
Le 13/01/2013 00:18, Brandon Benvie a écrit :
This isn't exactly a direct parallel because all the types that are
included as part of ES6 will be proxyable in such a way that the proxy
can be transparently interchanged with its target. The problem with
DOM objects is that this isn't true. I
I agree with that. This isn't something that belongs in ECMAScript, it's
out of scope. As you said, this is a conversation that needs to be had in
the space of DOM specifications/implementations.
On Sat, Jan 12, 2013 at 6:30 PM, David Bruant bruan...@gmail.com wrote:
Le 13/01/2013 00:18,
Le 13/01/2013 00:09, Nathan Wall a écrit :
hmm.. I just realized that B doesn't have direct access to O. So even if B does
have access to M, trying to get N from P[M] would expose N to the membrane.
Yes and once the membrane has captured N, it has to search again if some
object use in A---B
my concern is about security problems too but at least having this spec'ed
somewhere as known gotcha that cannot be solved not in the ECMAScript
domain would be better than nothing.
br
On Sat, Jan 12, 2013 at 3:30 PM, David Bruant bruan...@gmail.com wrote:
Le 13/01/2013 00:18, Brandon Benvie
double negation ... that cannot be solved in the ECMAScript domain
yeah!
On Sat, Jan 12, 2013 at 3:36 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
my concern is about security problems too but at least having this spec'ed
somewhere as known gotcha that cannot be solved not
David Bruant wrote:
Yes and once the membrane has captured N, it has to search again if some
object use in A---B communication has an N property... and restart all
over if an object does and has another private name attached.
Theoretically, the membrane can always be one step ahead of the
Le dim. 13 janv. 2013 00:43:29 CET, Nathan Wall a écrit :
David Bruant wrote:
Yes and once the membrane has captured N, it has to search again if some
object use in A---B communication has an N property... and restart all
over if an object does and has another private name attached.
I'm still reluctant to give up on the unknownPrivateSymbol trap, because
doing so means giving up on mediation for one case.
In this case, we were able to capture every single private symbol passed
back and forth, but in another situation, maybe we didn't create A and B.
Someone else created
Le 11/01/2013 06:46, Nathan Wall a écrit :
David Bruant wrote:
For the long term, I expected DOM objects could be proxified.
Boris convinced me otherwise for DOM Nodes at least.
Are you so convinced that the `unknownPrivateSymbol` trap is necessary?
I would think so, for instance, when one
Le 09/01/2013 23:57, Andrea Giammarchi a écrit :
do you have any example of what you are saying? all my examples fail
and I don't understand other use cases.
I don't. You seem to be relying a lot on the Firefox implementation, but
there are 2 things to be aware of as far as I know (sorry I
David Bruant wrote:
For the long term, I expected DOM objects could be proxified.
Boris convinced me otherwise for DOM Nodes at least.
Are you so convinced that the `unknownPrivateSymbol` trap is necessary?
It's been decided early that a Proxy.isProxy method should be avoided,
because
function isNodeProxy(node) {
try {
return node instanceof Node
document.body.appendChild(node)
!!document.body.removeChild(node);
} catch(x) {
return false;
}
}
Excuse me, I got the logic wrong:
Jason Orendorff wrote:
On Tue, Jan 8, 2013 at 11:54 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Boris and I talked more 1:1 -- it is not clear when a direct proxy
can be safely cast to its target. The internal proxies Gecko
uses are known implementations
Le 08/01/2013 22:59, Erik Arvidsson a écrit :
On Tue, Jan 8, 2013 at 4:46 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
One idea would be in the short term that implementations reliably
*always* throw when trying to wrap non-ECMAScript objects and play
with
Le 09/01/2013 06:57, Boris Zbarsky a écrit :
And specifically, it's not clear what the behavior should be when
there are two different scripted proxies for the same WebIDL object.
Say it's a DOM node. One of the proxies gets passed to appendChild.
When later getting that node out of the DOM
all this reminds me, hilariously, the Object.defineProperty case in
Internet Explorer 8 ... the infamous implementation that works only on
global and DOM objects. Here we have the opposite behavior, something so
powerful that could let us redefine W3C specs or eventually make them
consistent
Le 09/01/2013 14:55, Andrea Giammarchi a écrit :
all this reminds me, hilariously, the Object.defineProperty case in
Internet Explorer 8 ... the infamous implementation that works only on
global and DOM objects. Here we have the opposite behavior, something
so powerful that could let us
On 1/9/13 5:24 AM, David Bruant wrote:
When later getting that node out of the DOM with .firstChild, what
should be handed back? The proxy that was passed in, the JS object
that proxy was wrapping, something else (e.g. an exception is thrown)?
The principle of least surprise would say the
only part I am slightly skeptical is that if developers cannot use
proxies with DOM nodes there's really not much to wait for ... they'll not
use them, end of the story.
If you mean waiting for developers to complain same way I did ... oh
well, I think is just a matter of time. I'll be here that
On Tuesday, January 8, 2013, Tab Atkins Jr. wrote:
On Tue, Jan 8, 2013 at 12:40 PM, Andrea Giammarchi
andrea.giammar...@gmail.com javascript:; wrote:
So, I am playing with FF 18 and I have this behavior:
var a = new Proxy([], {});
console.log(a instanceof Array); // true
On Tue, Jan 8, 2013 at 11:54 PM, Brendan Eich bren...@mozilla.com wrote:
Boris and I talked more 1:1 -- it is not clear when a direct proxy can be
safely cast to its target. The internal proxies Gecko uses are known
implementations where this is safe (with a security check). An arbitrary
When later getting that node out of the DOM with .firstChild, what
should be handed back? The proxy that was passed in, the JS object
that proxy was wrapping, something else (e.g. an exception is thrown)?
The principle of least surprise would say the proxy that was passed in
That's
On 1/9/13 11:30 AM, François REMY wrote:
However, this second problem is not related to the DOM but to
globally accessible variables.
Well, right, but the DOM sort of forces the problem on us because of
window.document.
No membrane system can be secure through global variable access, so
we
Le 08/01/2013 22:23, Tab Atkins Jr. a écrit :
Meanwhile, there is unforgeable magic
behind DOM objects, and nothing we can really do about it.
Do you have examples? Besides document.all being falsy, everything seem
to be emulable with ES6 proxies.
David
Le 09/01/2013 16:02, Boris Zbarsky a écrit :
On 1/9/13 5:24 AM, David Bruant wrote:
When later getting that node out of the DOM with .firstChild, what
should be handed back? The proxy that was passed in, the JS object
that proxy was wrapping, something else (e.g. an exception is thrown)?
The
On 1/9/13 12:13 PM, David Bruant wrote:
There is some data associated with the object. Whether it's a (private)
property or a map entry is an implementation detail
...
Choosing symbols or a weakmap would make a huge difference in how proxy
replacement would react to DOM algorithms.
Then it's
Le 09/01/2013 19:43, Boris Zbarsky a écrit :
On 1/9/13 1:23 PM, David Bruant wrote:
What happens if unknownPrivateSymbol throws?
I'm not sure yet. My guess is that the error should be propagated
So just to make sure we're on the same page here... Say I have a
proxy for a div and I put it
On 1/9/13 2:45 PM, David Bruant wrote:
Debattable. Here, there is no need to work with private state. The
nodeType and tagName and parentNode (all public) are enough to do the
matching I think.
No, because script can override them but matching needs to not depend on
that, right?
So the
David ? You said: It could still make sense to wrap a DOM Node with a
proxy to perform [[Get]] and [[Set]], etc. but definitely not put it in the
DOM tree.
so this is the current scenario ... now, can you explain me a single case
where you would need that? If you can't use the DOM node then why
Last, but not least, even offline DOM proxies are pointless, here another
example without putting them in the DOM
var p = new Proxy(
document.createElement(p),
{}
);
try {
p.appendChild(
document.createElement(span)
);
} catch(o_O) {
console.log(o_O.message);
}
try {
Le 09/01/2013 21:30, Andrea Giammarchi a écrit :
David ? You said: It could still make sense to wrap a DOM Node with a
proxy to perform [[Get]] and [[Set]], etc. but definitely not put it
in the DOM tree.
so this is the current scenario ... now, can you explain me a single
case where you
Le 09/01/2013 21:57, Andrea Giammarchi a écrit :
Last, but not least, even offline DOM proxies are pointless, here
another example without putting them in the DOM
What's an offline DOM Proxy?
var p = new Proxy(
document.createElement(p),
{}
);
try {
p.appendChild(
That's what you
do you have any example of what you are saying? all my examples fail and I
don't understand other use cases.
As you said, if a Proxy should be undetectable a broken Proxy that cannot
be used is a pointless object full of inconsistency in the environment,
IMHO.
Is this the decision then? Let the
forgto this: yes, offline DOM node means a DOM that is not part of the live
DOM tree ... that is, indeed, disconnected, offline, no CSS, no repaint, no
reflow, nothing ... is offline. Isn't this term good enough? I thought that
makes sense
On Wed, Jan 9, 2013 at 2:57 PM, Andrea Giammarchi
This is a known problem called Object identity. We already have this problem
today with Object.create(document.createElement(p)) which is an instanceof
HTMLElement but is invalid for any DOM purpose.
However, if you take the same P element and set its __proto__ to null, it will
still be a
never even tried that since cloneNode() has been good enough but Proxies
are more powerful than just inheritance so, as it is now, we are trapped
for the DOM while Object.observe(), if I remember correctly, was
reacting/working with DOM too plus makes object somehow proxified or
better observed.
Since proxies always have a target, it would be simple enough for the DOM
internally to use the proxy target. As to whether that's going to happen, I
guess that would be up to implementers.
On Tue, Jan 8, 2013 at 4:15 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
never even tried
On Tue, Jan 8, 2013 at 12:40 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So, I am playing with FF 18 and I have this behavior:
var a = new Proxy([], {});
console.log(a instanceof Array); // true
console.log(Array.isArray(a)); // true
console.log({}.toString.call(a));// [object
: Re: direct_proxies problem
From: bran...@brandonbenvie.com
To: andrea.giammar...@gmail.com
CC: francois.remy@outlook.com; es-discuss@mozilla.org
Since proxies always have a target, it would be simple enough for the
DOM internally to use the proxy target. As to whether that's going
so you are saying that Object.observe() does not suffer these problems ? Or
is just much simpler than Proxies ? ( yeah, I know, I guess both ... )
On Tue, Jan 8, 2013 at 1:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jan 8, 2013 at 12:40 PM, Andrea Giammarchi
On Tue, Jan 8, 2013 at 1:30 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
so you are saying that Object.observe() does not suffer these problems ? Or
is just much simpler than Proxies ? ( yeah, I know, I guess both ... )
I believe it just wouldn't suffer the same problems - it needs
On Tue, Jan 8, 2013 at 4:30 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
so you are saying that Object.observe() does not suffer these problems ? Or
is just much simpler than Proxies ? ( yeah, I know, I guess both ... )
Object.observe is different, it works on at [[Get]], [[Put]],
On Tue, Jan 8, 2013 at 4:46 PM, David Bruant bruan...@gmail.com wrote:
One idea would be in the short term that implementations reliably *always*
throw when trying to wrap non-ECMAScript objects and play with them as if
they were legit browser objects. If the need becomes strong,
ooops, that's a typo, the toString is HTMLParagraphElement or the correct
one.
The problem I have here is with identity indeed where this is same as
target in JS world and something else behind the scene in C++ world ...
this is bad because we cannot recognize proxies and we cannot then avoid
We could potentially switch from magic to private symbols but DOM
bindings are highly optimized and I don't think we could afford making
these use symbols. (Right now the pointer is stored at a statically
know offset of the js object.)
Can we use both systems in parallel? In case you hit the
On Jan 8, 2013, at 1:23 PM, Tab Atkins Jr. wrote:
This is a problem elsewhere, too - Web Components really wants to make
it easy to subclass DOM objects, but we've had to twist ourselves into
knots to do it in a way that alerts the C++ side early enough that
it can create the new objects
François REMY wrote:
In case you hit the invalid cast case, you can check if you
received a Proxy. If you received a proxy, you retry the cast using
its target instead.
For what it's worth, this is exactly how Gecko's WebIDL bindings work.
We use something much like a Proxy to enforce
On 1/9/13 12:54 AM, Brendan Eich wrote:
Boris and I talked more 1:1 -- it is not clear when a direct proxy can
be safely cast to its target. The internal proxies Gecko uses are
known implementations where this is safe (with a security check).
And the reason it's safe is that when you then get
63 matches
Mail list logo
