This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Selective quote from Boris http://lists.w3.org/Archives/Public/www-tag/2014Jan/0112.html below: > Here's what WebIDL says: > > Every platform object is associated with a global environment, just > as the initial objects are. It is the responsibility of > specifications using Web IDL to state which global environment > (or, by proxy, which global object) each platform object is > associated with. > > Here's an example not involving promises that's currently underspecified, I > believe: > > window1.document.createElement.call(window2.document, "span"); > > I've put the relevant testcase at > http://web.mit.edu/bzbarsky/www/testcases/multiple-realms/createElement-1.html > if you want to take a look. Browsers consistently create the element in the > realm of window2 in this case, but the DOM spec doesn't seem to actually > define the behavior right now, unless I'm totally missing something. It > should do so, for example by defining that an element is associated with the > global environment of its owner document and then defining the global > environment for documents as needed. DOMParser and XMLHttpRequest make that > last bit slightly exciting. I guess I'll file follow up bugs once I fix this in DOM.
Anne, thank you. I should have filed this. :(
Events are associated with the global environment of their interface object (better term?). Nodes are associated with the global environment of their node document. Documents are associated with the global environment of "depends". Ranges are associates with the global environment of the context object of the method that created them or their interface object in case of constructors. NodeIterator and TreeWalker are associated with the global environment of the context object of the method that created them. Attr and DOMTokenList need to inherit from their associated element. Collections probably need to inherit from the context object of the method that creates them. I wonder if some of the inheriting should be expressed using IDL. That would make it easier for people to define new APIs.
(In reply to Anne from comment #2) > I wonder if some of the inheriting should be expressed using IDL. That would > make it easier for people to define new APIs. E.g. if an interface has [Constructor] its associated global will be the one of its interface object. If an object is returned by a member of another object its associated global will be the same as that other object (with some kind of exception for <iframe> I suppose). Or am I completely wrong here?
> Events are associated with the global environment of their interface object Except for events directly created via |new FooEvent|, that just moves the question to "well, which interface object is the relevant one"? The rest sound reasonable to me.
> Or am I completely wrong here? You're not. What Gecko implements is that a particular implementation object can specify which global it should live in by returning some other object whose global should be used. For example, nodes return their owner document; documents return a global stashed on them when they're created. If an object in Gecko does not specify a global to use, the global that's used is the global of the getter/method that's returning the object to JS. So if you do: var r = windowA.document.createRange.call(windowB.document); we create "r" in the global of window A. There's one complication here if JS reflections don't have the same lifetime as the underlying object and the object can be returned from various different getters/methods. But that might just be an implementation detail. Not sure. The basic question is what should happen if a preexisting object is stashed somewhere and then retrieved.
Given https://github.com/w3c/web-platform-tests/pull/1381 this is entirely an IDL problem. Resolving WONTFIX for DOM.
I'm not sure I see what that pull request for wpt has to do with this bug. How is this entirely an IDL problem?
That pull request was about demonstrating to you whether this could be done predictably, and defined by IDL. Bug 24652, which this bug depends on, is the actual IDL bug.
Ah, I see. It's still not clear to me whether we can entirely define this in IDL, but we can try... we just need to do it, because right now browsers are basically doing whatever the heck they want for new APIs.