On 2012/11/22 12:17:05, rossberg wrote:
I think the most important case to test for would be one that reuses a
detached
global with a different context. In that state, should one continue to
observe
any changes? What if the original context gets destroyed?
I'm not sure how the current implementation would react in that case,
because
it
seems to be associating the info with the global object proper, not the
global
proxy?
I've added a test where we take a global proxy and attach it to a different
context, so you can see the behavior. The behavior is that any previous
observations are still attached to the "old" global, which seems right to me
since that's the global which is accessible via "this" after detachment.
After
re-attachment, observing the proxy is equivalent to observing the new
global.
This all seems pretty logical to me, but I agree that abarth's input on the
security implications would be valuable.
I also recall that, in addition to global proxies, the WebKit binding
makes
extensive use of hidden prototypes to implement the global object. That's
a
similar but different mechanism. We probably need tests for that stuff as
well.
To be honest, I'm not entirely sure either what the desired semantics
should
be
for all these things. Adding Adam Barth to CC, maybe he can shed some
light on
the global object madness in WebKit/V8, and how it should interact with
observation. :)
https://codereview.chromium.org/11414094/diff/1/src/runtime.cc
File src/runtime.cc (right):
https://codereview.chromium.org/11414094/diff/1/src/runtime.cc#newcode13248
src/runtime.cc:13248: if (key->IsNull()) return
isolate->heap()->undefined_value();
On 2012/11/21 17:02:57, adamk wrote:
> On 2012/11/21 12:43:17, rossberg wrote:
> > False here, too.
>
> This function wasn't carrying its weight, just removed and implemented
in
JS.
I'm fine with that. But note that there no longer is a way to
differentiate
between an absent key and a key mapping to 'undefined'. Not that anybody
should
ever need that...
https://codereview.chromium.org/11414094/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
