Sorry, I stupidly put the wrong example in (and stupidly sent to
chromium-dev from the wrong email address, so sorry to anyone who gets this
twice) - it does give me the chance to fix a typo Adam pointed out:
parent page:
function getImage() {
return new *parent.window.*Image();
}
child frame:
var image1 = new parent.window.Image();
var image2 = parent.window.getImage();
In Firefox, image1.__proto__ === image2.__proto__. In WebKit, they don't
match.
I put this discussion onto chromium-dev primarily since I wanted to
understand the v8 APIs.
Anyhow, I'll ping Adam directly with the rest of my questions to avoid
either boring the rest of the list :)
-atw
On Thu, Jul 9, 2009 at 3:46 PM, Drew Wilson <[email protected]> wrote:
> Sorry, I stupidly put the wrong example in:
> parent page:
>
> function getImage() {
> return new *parent.window.*Image();
> }
>
> child frame:
>
> var image1 = new parent.window.Image();
> var image2 = new parent.window.getImage();
>
> In Firefox, image1.__proto__ === image2.__proto__. In WebKit, they don't
> match.
>
> I put this discussion onto chromium-dev primarily since I wanted to
> understand the v8 APIs.
>
> Anyhow, I'll ping Adam directly with the rest of my questions to avoid
> either boring the rest of the list :)
>
> -atw
>
>
> On Thu, Jul 9, 2009 at 1:26 PM, Adam Barth <[email protected]> wrote:
>
>> On Thu, Jul 9, 2009 at 1:04 PM, Drew Wilson<[email protected]> wrote:
>> > Hi all,
>> > I've been poking around quite a bit recently in the WebKit JS
>> > bindings/constructor code, trying to make some sense of their widespread
>> use
>> > of the lexicalGlobalObject() - basically, it seems like looking at the
>> > lexicalGlobalObject() is seldom what they actually want, because it
>> means
>> > that if you call between frames you unexpectedly start pulling things
>> from a
>> > different context.
>> > As a very simple example (bear with me, I'll get to the chrome-specific
>> > question in a second) - imagine that you have a page containing a child
>> > frame. In the parent page, you define this:
>> > function getImage() {
>> > return new Image();
>> > }
>> > ...now down in your child frame, you have code that does this:
>> > var image1 = new Image();
>> > var image2 = parent.window.getImage();
>> > assert(image1.__proto__ == image2.__proto__); // Fails in WebKit
>> currently,
>> > because the Image constructor lookup uses the lexicalGlobalObject.
>> >
>> > JSC defines dynamicGlobalObject() and lexicalGlobalObject() - I suspect
>> that
>> > they generally want to be using dynamicGlobalObject instead of
>> > lexicalGlobalObject when trying to access something from global scope.
>> Or am
>> > I missing some subtlety here?
>>
>> dynamicGlobalObject() is almost never the right choice. The correct
>> result for the image constructor is based on the window that
>> originally holds the image constructor. The assert above should fail,
>> but the result JSC computes is still wrong.
>>
>> > That brings me to my Chromium/V8 question - there are 3 context-grabbing
>> > functions in V8: GetEntered(), GetCalling(), GetCurrent(). When is it
>> > appropriate to use one over the others (what are the effective
>> differences)?
>>
>> GetEntered() ~ dynamicGlobalObject
>> GetCalling() ~ lexicalGlobalObject
>> GetCurrent() ~ *concept doesn't exist in JSC*
>>
>> > The descriptions are kind of terse, and I'm afraid I'm missing some of
>> the
>> > subtleties between "the context of the calling JavaScript code" vs "The
>> > context on the top of the stack" vs "The last entered context" (for
>> example,
>> > I would have naively thought that the calling JavaScript code's context
>> > would *inherently* be the last entered one, and hence would be on the
>> top of
>> > the stack, but clearly that's not true :)
>>
>> These things are easier to understand by example. You can contact me
>> directly and we can go through some examples.
>>
>> In any case, we should have this discussion on webkit-dev because it
>> affects the webkit.org repository.
>>
>> Adam
>>
>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
