On 2015/07/10 13:22:16, Toon Verwaest wrote:
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.
Yes, and that's not great, but what would you rather do? We can't just try
to
retrieve the property and throw --- we need to either not access the
property
(which will break access-checked objects that pass the access check ---
maybe
that's fine, maybe not) --- or to just ignore the failed access check and
fallback on a sane behaviour.
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?
If we don't do anything, and just leave it as-is, we break things (as seen
in
https://code.google.com/p/chromium/issues/detail?id=507553)
If we know the object is special in this way, then sure we could just avoid
retrieving the property, which accomplishes the same thing as this --- with
one
exception: if an access check is needed, but allowed, it does the wrong
thing
even for safe objects.
"What is the use-case for spreading Window or Location"? It doesn't matter
what
the use-case is, because failing the access check breaks "concat" period,
whether they intended to spread or not.
I really don't like this; if it wasn't clear :)
Well, what would you like? That's a more helpful thing.
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.
Well, it makes the test simpler --- it doesn't have to be a real-world
example.
If it's going to stop working, then I'll put the time in to make it work.
But
there isn't much point of that if we're not going to do it this way. So,
given
that we can't just throw when the access check fails, and you don't like the
fallback value idea, what would you prefer? Constructive criticism is
appreciated
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.
