CQ is trying da patch. Follow status at
https://chromium-cq-status.appspot.com/patch-status/1230793002/230001
View timeline at
https://chromium-cq-status.appspot.com/patch-timeline/1230793002/230001
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
Patchset 12 (id:??) landed as
https://crrev.com/8561dbd655769cb63fc797e7ebd3923bee943212
Cr-Commit-Position: refs/heads/master@{#31131}
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this
Committed patchset #12 (id:230001)
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
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
CQ is trying da patch. Follow status at
https://chromium-cq-status.appspot.com/patch-status/1230793002/21
View timeline at
https://chromium-cq-status.appspot.com/patch-timeline/1230793002/21
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
On 2015/10/06 16:58:27, caitp wrote:
On 2015/10/06 16:56:25, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
> v8_linux64_asan_rel on tryserver.v8 (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel/builds/8652)
>
CQ is trying da patch. Follow status at
https://chromium-cq-status.appspot.com/patch-status/1230793002/220001
View timeline at
https://chromium-cq-status.appspot.com/patch-timeline/1230793002/220001
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
On 2015/10/06 16:56:25, commit-bot: I haz the power wrote:
Try jobs failed on following builders:
v8_linux64_asan_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel/builds/8652)
v8_linux64_avx2_rel on tryserver.v8 (JOB_FAILED,
Try jobs failed on following builders:
v8_linux64_avx2_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel/builds/5021)
v8_mac_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel/builds/10414)
Try jobs failed on following builders:
v8_linux64_asan_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel/builds/8652)
v8_linux64_avx2_rel on tryserver.v8 (JOB_FAILED,
On 2015/10/05 16:44:56, caitp wrote:
On 2015/10/05 16:41:14, adamk wrote:
> I'm happy that Toon is happy with this approach. I'm still a bit worried
about
> the "not yet specced" part, though, especially as we're adding this new
behavior
> to existing Symbols. Is there a reason not to start
lgtm with an updated CL description noting that this only changes behavior
for
@@isConcatSpreadable for now.
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are
I'm happy that Toon is happy with this approach. I'm still a bit worried
about
the "not yet specced" part, though, especially as we're adding this new
behavior
to existing Symbols. Is there a reason not to start this with only allowing
window[@@isConcatSpreadable] to return undefined?
On 2015/10/05 16:41:14, adamk wrote:
I'm happy that Toon is happy with this approach. I'm still a bit worried
about
the "not yet specced" part, though, especially as we're adding this new
behavior
to existing Symbols. Is there a reason not to start this with only
allowing
https://codereview.chromium.org/1230793002/diff/160001/src/objects.cc
File src/objects.cc (right):
https://codereview.chromium.org/1230793002/diff/160001/src/objects.cc#newcode997
src/objects.cc:997: if (!it->IsElement()) {
On 2015/10/02 10:01:15, caitp wrote:
On 2015/10/02 08:05:27, Toon
I've written http://caitp.github.io/spidermonkey-wks-security/ to help
track all
of the behaviours of cross-origin access to symbol hooks. It's missing a
lot of
stuff, but it might be useful later on
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
https://codereview.chromium.org/1230793002/diff/160001/src/objects.cc
File src/objects.cc (right):
https://codereview.chromium.org/1230793002/diff/160001/src/objects.cc#newcode997
src/objects.cc:997: if (!it->IsElement()) {
On 2015/10/02 08:05:27, Toon Verwaest wrote:
Rather than if
https://codereview.chromium.org/1230793002/diff/160001/src/objects.cc
File src/objects.cc (right):
https://codereview.chromium.org/1230793002/diff/160001/src/objects.cc#newcode997
src/objects.cc:997: if (!it->IsElement()) {
On 2015/10/02 10:07:01, Toon Verwaest wrote:
On 2015/10/02 10:01:15,
@adamk: if we later need other behavior for other symbols, we could switch
in
...WithFailedAccessCheck over a well-known-symbol "id". So far (and it seems
like the only thing that makes sense to me) any spec'd behavior on failed
access
check has a predictable result. E.g.,
lgtm, thanks
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
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
Last patch looks good from my side. Some additional comments.
https://codereview.chromium.org/1230793002/diff/160001/src/objects.cc
File src/objects.cc (right):
https://codereview.chromium.org/1230793002/diff/160001/src/objects.cc#newcode997
src/objects.cc:997: if (!it->IsElement()) {
Rather
https://codereview.chromium.org/1230793002/diff/140001/src/objects.cc
File src/objects.cc (right):
https://codereview.chromium.org/1230793002/diff/140001/src/objects.cc#newcode662
src/objects.cc:662: access_check_failed = false;
This alternative implementation doesn't change the nature of
New patch set does not throw for loads of spec'd symbol hooks ever, so but
still
throws on writes, and probably throws on [[HasProperty]] tests too.
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You
On 2015/10/01 15:30:13, Toon Verwaest wrote:
I still stand by my previous comments. I don't want access checks to be
exposed
by GetProperty.
How about something like "GetWellKnownSymbolHook()" instead? It doesn't
really
matter what it's called, but whatever it is needs to let the caller
I still stand by my previous comments. I don't want access checks to be
exposed
by GetProperty.
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the
include/ lgtm
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
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
On 2015/07/18 07:59:19, Toon Verwaest wrote:
What about setting a bit on symbols whether they are "absent on access
check
failure", and extend GetProperty(Attributes)WithFailedAccessCheck to also
handle
such symbols in addition to all_can_read accessors and interceptors? That
way
it
On 2015/09/29 21:48:28, adamk wrote:
On 2015/07/18 07:59:19, Toon Verwaest wrote:
> What about setting a bit on symbols whether they are "absent on access
check
> failure", and extend GetProperty(Attributes)WithFailedAccessCheck to
also
handle
> such symbols in addition to all_can_read
On 2015/09/29 21:49:18, adamk wrote:
On 2015/09/29 21:48:28, adamk wrote:
> On 2015/07/18 07:59:19, Toon Verwaest wrote:
> > What about setting a bit on symbols whether they are "absent on access
check
> > failure", and extend GetProperty(Attributes)WithFailedAccessCheck to
also
> handle
> >
What about setting a bit on symbols whether they are absent on access check
failure, and extend GetProperty(Attributes)WithFailedAccessCheck to also
handle
such symbols in addition to all_can_read accessors and interceptors? That
way it
becomes very easy to support a new symbol by just
With an all-can-read property you can still return whatever you want for
iframes
that don't have access. See
But obviously it's still visibly different from what Boris suggests, given
that
the property is there.
As I've suggested in another thread, we *could* use all-can-read
interceptors to
achieve both all-can-read and absent, but that's kinda ugly ... We could
support
invisible all-can-read
Yes. That what I meant with my all-can-read suggestion; that's the same
thing.
If that's a workable solution I'd much prefer that. I presume we'd only
need it
on window though, not on location?
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
On 2015/07/11 at 17:09:02, caitpotter88 wrote:
On 2015/07/10 17:24:39, adamk wrote:
Just to link discussions together further, the spec-world discussion
about
this
is taking place at:
https://lists.w3.org/Archives/Public/public-script-coord/2015JulSep/0022.html
Per the discussion in
On 2015/07/13 18:12:49, adamk wrote:
On 2015/07/11 at 17:09:02, caitpotter88 wrote:
On 2015/07/10 17:24:39, adamk wrote:
Just to link discussions together further, the spec-world discussion
about
this
is taking place at:
On 2015/07/13 at 18:20:59, caitpotter88 wrote:
On 2015/07/13 18:12:49, adamk wrote:
On 2015/07/11 at 17:09:02, caitpotter88 wrote:
On 2015/07/10 17:24:39, adamk wrote:
Just to link discussions together further, the spec-world discussion
about
this
is taking place at:
On 2015/07/10 17:24:39, adamk wrote:
Just to link discussions together further, the spec-world discussion about
this
is taking place at:
https://lists.w3.org/Archives/Public/public-script-coord/2015JulSep/0022.html
Per the discussion in the etherpad, the best thing to do is probably just
I think this needs to be thought trough by people writing the spec. This is
just
an ad-hoc workaround, which will likely not match whatever is later decided
as
the actual spec.
If you really need to get something in *right now* for whatever reason, I'd
only
sign off on *only* changing
(that should have been obj-IsAccessCheckNeeded()
!isolate-MayAccess(HandleJSObject::cast(obj)) I guess)
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed
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
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
Just to link discussions together further, the spec-world discussion about
this
is taking place at:
https://lists.w3.org/Archives/Public/public-script-coord/2015JulSep/0022.html
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
If a decision is made to return undefined or so in general, also through
the prototype chain, my approach obviously won't work. In that case we'll
have to think about an alternative that fits the rest of such special
properties, like installing an all-can-read api accessor for those
properties
+andreas
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
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
https://codereview.chromium.org/1230793002/diff/40001/test/cctest/test-api.cc
File test/cctest/test-api.cc (right):
https://codereview.chromium.org/1230793002/diff/40001/test/cctest/test-api.cc#newcode21910
test/cctest/test-api.cc:21910: LocalValue result2 =
CompileRun([].concat([global,
On 2015/07/09 13:55:00, caitp wrote:
Hi,
this is one approach which should maintain legacy behaviour when dealing
with
objects from a different origin. If the @@isConcatSpreadable symbol is
present,
Chromium can probably emit a warning as to why its value is ignored
test coming soon
https://codereview.chromium.org/1230793002/diff/40001/test/cctest/test-api.cc
File test/cctest/test-api.cc (right):
https://codereview.chromium.org/1230793002/diff/40001/test/cctest/test-api.cc#newcode21910
test/cctest/test-api.cc:21910: LocalValue result2 =
CompileRun([].concat([global,
I think I'm liking my minimal suggestion less now, since it could cause
us to
throw exceptions in new places if there are access-checked objects on the
prototype chain (still rare, but that makes another case).
So the approach here does seem attractive to me, will see if I can think of
a
A few comments, but as I say below, I think verwaest@ is the right reviewer
for
this approach.
The simpler approach of treating IsAccessCheckNeeded() as undefined seems
like
nearly as good a solution, though: the only thing it disallows in practice
is
making Window and Location objects
https://codereview.chromium.org/1230793002/diff/60001/test/cctest/test-api.cc
File test/cctest/test-api.cc (right):
https://codereview.chromium.org/1230793002/diff/60001/test/cctest/test-api.cc#newcode21889
test/cctest/test-api.cc:21889: LocalObject global_object =
https://codereview.chromium.org/1230793002/diff/20001/src/objects.h
File src/objects.h (right):
https://codereview.chromium.org/1230793002/diff/20001/src/objects.h#newcode1219
src/objects.h:1219: MUST_USE_RESULT static inline MaybeHandleObject
GetPropertyOrFallbackValue(
How about something
On 2015/07/09 17:17:25, adamk wrote:
I think I'm liking my minimal suggestion less now, since it could cause
us
to
throw exceptions in new places if there are access-checked objects on the
prototype chain (still rare, but that makes another case).
So the approach here does seem attractive
I'd like to wait for a bit more time on the public-script-coord thread,
though I
don't think we need to wait on changing Blink's whole Window object
implementation.
https://codereview.chromium.org/1230793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
52 matches
Mail list logo
