wow ...
do we really need this? I'm really really not in favor of any of this.
There's a spec-on-the-way for cross-origin access, which is very close to
what
Chrome does. See https://etherpad.mozilla.org/html5-cross-origin-objects
We can definitely not just look behind access checks, so if we really need
this,
then only returning a fallback value makes sense. But even that breaks what
would normally happen.
As adamk@ mentioned, access checks are only relevant for Window and
Location. Do
we really need special concat-spreadable support for those objects? What's
wrong
with just throwing as would happen if you wouldn't have a VM-supported
implementation?
I really don't like this; if it wasn't clear :)
https://codereview.chromium.org/1230793002/diff/80001/test/cctest/test-api.cc
File test/cctest/test-api.cc (right):
https://codereview.chromium.org/1230793002/diff/80001/test/cctest/test-api.cc#newcode21863
test/cctest/test-api.cc:21863: if (!name->IsSymbol()) return true;
Access checks are in the process of being rewritten to not get anything
in but the receiver and the context from which access is requested. At
this point type is already *always* ACCESS_HAS and "name" is *always*
undefined. Hence this IsSymbol check makes no sense.
Access checks shouldn't be finegrained, and cannot partially allow
access (minus some really internal things like hash-codes). Either you
have access from the current context to an object, or you don't.
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
