This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24652 - Deal with associated global / Realm
Summary: Deal with associated global / Realm
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
Depends on: 27356 27354 27355
Blocks: 24318 25099
  Show dependency treegraph
Reported: 2014-02-13 12:07 UTC by Anne
Modified: 2019-03-04 11:53 UTC (History)
9 users (show)

See Also:


Description Anne 2014-02-13 12:07:07 UTC
The realm of an object with a constructor is clear. It's the interface object's global object's realm.

There should be some way to indicate that if you get window.document, the Document object returned has the same realm as window. And some way to override that, consider <iframe>. (Maybe it should be a default with an explicit opt-out for complicated cases?)

Similarly, for document.createElement() the new Element object will have the same realm as document.

The complicated case that remains is objects passed to callbacks and events I suppose. Hopefully bug 24403 helps with that?
Comment 1 Boris Zbarsky 2014-02-13 15:11:05 UTC
The complicated case is any time an object can be gotten from more than one place, really.  You have to make sure all those places agree on which realm the object is in.
Comment 2 Dimitri Glazkov 2014-02-13 17:36:59 UTC
I mentioned Realms to Alex once, and he made a sour-lemon-face. He was worried they are not a good fit for the Web platform. Alex, can you help elaborate?
Comment 3 Anne 2014-10-31 18:18:51 UTC
Regardless of whether they're a good fit, security checks depend on them. is something that should be defined once this is fixed.
Comment 4 Boris Zbarsky 2014-10-31 18:31:12 UTC
Dimitri, Realm in this case is just a way to talk about the right global environment.  You have to define what global environment a given object is created in.  It's totally observable via instanceof Object (and in general in terms of which global's standard prototypes are used for the object being created).

The way ES handles this for objects it creates is by having a concept of "current Realm" and defining that unless specified otherwise any time an object is created it uses the standard prototypes of the global of the current Realm.
Comment 5 Anne 2014-11-11 11:51:51 UTC has a test. It seems [NewObject] APIs behave fairly consistently.


  JavaScript -> IDL -> API spec -> IDL -> JavaScript

perhaps the second instance of IDL can take care of setting the correct Realm when a new object is created.

That leaves cases such as window.document, window.document.implementation, ... I guess for those objects we should define the lifetime more clearly and use some kind of hook in IDL to set their Realm correctly. Given that those too go through the IDL -> API spec -> IDL cycle it does seem like IDL needs to say what aspects API specs need to define of an IDL value.
Comment 6 Anne 2014-11-17 20:03:14 UTC
To address this issue, I filed bug 27354, bug 27355, and bug 27356. I'm not sure if that leaves anything for this bug, but we can evaluate once the dependencies are fixed.
Comment 7 Boris Zbarsky 2016-03-14 13:17:26 UTC
There will be some complications with async algorithms, especially if they involve "this" values whose global can change (e.g. node adoption, if that changes the global)...