On 1/9/13 1:23 PM, David Bruant wrote:
I don't think anyone (me including) really took the time to write an
example of how unknownPrivateSymbol works either. Let's do that:
Thank you, that helps a lot.
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 in the DOM. Say my page has:
<style>
section > div { color: green; }
</style>
Should matching that selector against the div call unknownPrivateSymbol
when getting the parent of the div? If so, what should it do if it
throws? Note, by the way, that UAs are working on doing off-main-thread
selector matching and that the exact timing/ordering of selector
matching is not defined and won't be (because it's a state thing, not a
procedural algorithm), so doing anything script-observable anywhere here
is pretty weird.
On the other hand, selector matching allows one to exfiltrate things
like which attributes are set and to what values, as well as information
about the ancestors and often descendants of the element.
It would be up to spec writers of each sort of object to decide.
OK.
If the serialization algorithm is represented as a private symbol'ed
methods on objects, then, doing a [[Get]] with this symbol as argument
would call the unknownPrivateSymbol trap. The result of this trap (throw
or return (return value is ignored)) determines whether the algorithm is
actually called.
That wasn't my point. My point was what happens to the tree traversal
the serialization algorithm does if the firstChild member (not the
getter, the actual internal state that stores the first child) is
defined to be a private symbol?
unknownPrivateSymbol is a trap, so I'm not sure I understand your
question.
My question boils down to this: are we talking about introducing things
that would be able to modify a DOM tree while it's being iterated by
internal browser algorithms? Because doing that is not acceptable.
It sounds like so far the answer is "maybe, depending on how those
traversals are defined in the specs".
The trap in itself cannot do anything.
On the contrary, it can do anything any JS function on the page can do.
Best case, it forwards the operation to
the target, worst case, it cancels the operation entirely.
No, worst case it calls document.open() or window.close() or spins the
event loop via showModalDialog or any of a number of other interesting
things script can do.
The trap in itself can't do anything. The code in it is a function which
can't do anything more than what a function can do today.
That's a _really_ interesting definition of "can't do anything".
Functions today can totally destroy the world (as in, the entire web
page they're running in). The only saving grace is that they can only
be invoked at particular safe points when you allow the world to be
destroyed.
Any proposal that would allow random functions to be invoked in too many
cases is dead in the water from a security and performance standpoint.
It can have side-effects, the only important case is whether a public
method call result in 0 or 1+ calls on a given object.
Uh... no. How can that be the only important case???
What I meant
above (but didn't say) is that whether it's called (0 or 1) is
important, but if it's 1 or 5 times for a given public method call, it
doesn't matter much.
For a function with side-effects this seems blatantly false to me, so I
must be missing something. What am I mising?
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
