Merge global object and environment settings object #167
Comments
This fixes the following from #164: * It gives workers a base URL that matches the response's url. Per https://www.w3.org/Bugs/Public/show_bug.cgi?id=28835 this matches Firefox and would also be more consistent with how the platform determines base URLs in general. (The fix is slightly ugly as it puts the URL on the global object so it can be overridden later. In HTML Standard theory the global object is optional and non-JavaScript languages need not provide it, but I think we should move away from that: #167.) * It keys shared worker on constructor URL rather than "location". The latter takes redirects into account and if implemented results in racy behavior. Fortunately, neither Chrome nor Firefox implemented this and instead already use this new "constructor url" concept. * It references "in parallel" where used. * It defaults name to the empty string through IDL.
|
Looking at https://tc39.github.io/ecma262/#sec-code-realms it seems like the intended primitive might be realms. Although we have the usual problem where ES does not acknowledge the global object vs. global proxy distinction. Hmm. |
|
Some more discussion in IRC. Here I think is what I would do:
|
|
Soooooo per https://html.spec.whatwg.org/#initialise-the-document-object 2.1's note, this is not 1:1 at all. There are many global objects (Window objects) for each environment settings object. environment settings objects <-> Realms <-> browsing contexts <-> WindowProxy, but not global objects. |
|
Wait, global objects are not 1:1 with realms? That does not seem right. And according to @bzbarsky settings objects are 1:1 with globals in at least Gecko. (I'm not sure it matters much since settings objects only have getters, but it still seems wrong for there to be this big mismatch in understanding.) |
|
Realms are 1:1 with globals. Neither of those are 1:1 with browsing contexts. Further, note that step 1 of the thing linked from #167 (comment) associates the settings object with a particular global object (window). Since that window never changes, things like the origin of the settings object never change. Now as for the note being mentioned... it's a partial lie. A new settings object is created at https://html.spec.whatwg.org/#dom-document-open step 17 for example. But it's true that one is not created during navigation, and that's broken. Looks to me like there was a plan to have a settings object be per-browsing-context and highly mutable (a bad idea, imo), then people tried to change to having it per-global and less mutable, but didn't do it right. Or the other direction. I agree the current state of the spec is certainly very broken. |
|
Oh, I guess navigation does explicitly mutate the "window" of the settings context. So ok, the main inconsistency is between that and |
|
One other thing: if we go with attaching the environment settings object to the browsing context, and scripts get things like their origin from it (which they do), then we have a problem: anything that uses the origin of the incumbent settings object is broken, because once you navigate the settings object stays the same but its origin changes. So calling a function in a navigated-away-from window will use the incumbent settings object of the browsing context that function's global came from... which can have whatever origin you want, since you can navigate it wherever you want. This is not desirable, obviously. |
|
It seems like I unintentionally messed things up a while back. Today I will work on reverting to having environment settings objects and realms be 1:1 with globals. See #322 (comment) for a bit more. |
See #167 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=27204. This makes it clear that environment settings objects, realms, and global objects are 1:1:1, giving explicit names and paths for getting from each to the other (of which 5/6 are already used in this spec). It also introduces the "new" concept of "current settings object" as a shorthand for "the current Realm Record's settings object", since that was already being used in two places. This does not yet fix #473, nor does it yet create definitions for {incumbent, entry, current} {settings object, Realm, global object} like I planned in #167 (comment).
See #167 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=27204. This makes it clear that environment settings objects, realms, and global objects are 1:1:1, giving explicit names and paths for getting from each to the other (of which all are already used in this spec). It also introduces the "new" concept of "current settings object" as a shorthand for "the current Realm Record's settings object", since that was already being used in two places. This does not yet fix #473, nor does it yet create definitions for {incumbent, entry, current} {settings object, Realm, global object} like I planned in #167 (comment).
See #167 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=27204. This makes it clear that environment settings objects, realms, and global objects are 1:1:1, giving explicit names and paths for getting from each to the other (of which all are already used in this spec). It also introduces the "new" concept of "current settings object" as a shorthand for "the current Realm Record's settings object", since that was already being used in two places. This does not yet fix #473, nor does it yet create definitions for {incumbent, entry, current} {settings object, Realm, global object} like I planned in #167 (comment).
See #167 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=27204. This makes it clear that environment settings objects, realms, and global objects are 1:1:1, giving explicit names and paths for getting from each to the other (of which all are already used in this spec). It also introduces the "new" concept of "current settings object" as a shorthand for "the current Realm Record's settings object", since that was already being used in two places. This does not yet fix #473, nor does it yet create definitions for {incumbent, entry, current} {settings object, Realm, global object} like I planned in #167 (comment).
This adds a new section under scripts detailing the entry, incumbent, current, and relevant concepts with regard to realms/global objects/ environment settings objects. This centralizes information that was previously somewhat spread out, and adds lots of details, as well as an example. This takes care of some of the pain points noted in #473, in particular fixing the definition of entry settings object to be more clearly defined in terms of the JavaScript execution context stack. There is still some work to do in that issue: namely, updating Web IDL with regard to tracking the entry settings object, and also making sure that incumbent settings object is correctly defined. This closes #167 by finally implementing the plan in #167 (comment) for making the correspondences clear.
This adds a new section under scripts detailing the entry, incumbent, current, and relevant concepts with regard to realms/global objects/ environment settings objects. This centralizes information that was previously somewhat spread out, and adds lots of details, as well as an example. This takes care of some of the pain points noted in #473, in particular fixing the definition of entry settings object to be more clearly defined in terms of the JavaScript execution context stack. There is still some work to do in that issue: namely, updating Web IDL with regard to tracking the entry settings object, and also making sure that incumbent settings object is correctly defined. This closes #167 by finally implementing the plan in #167 (comment) for making the correspondences clear.
This adds a new section under scripts detailing the entry, incumbent, current, and relevant concepts with regard to realms/global objects/ environment settings objects. This centralizes information that was previously somewhat spread out, and adds lots of details, as well as an example. This takes care of some of the pain points noted in #473, in particular fixing the definition of entry settings object to be more clearly defined in terms of the JavaScript execution context stack. There is still some work to do in that issue: namely, updating Web IDL with regard to tracking the entry settings object, and also making sure that incumbent settings object is correctly defined. This closes #167 by finally implementing the plan in #167 (comment) for making the correspondences clear.
This adds a new section under scripts detailing the entry, incumbent, current, and relevant concepts with regard to realms/global objects/ environment settings objects. This centralizes information that was previously somewhat spread out, and adds lots of details, as well as an example. This takes care of some of the pain points noted in #473, in particular fixing the definition of entry settings object to be more clearly defined in terms of the JavaScript execution context stack. There is still some work to do in that issue: namely, updating Web IDL with regard to tracking the entry settings object, and also making sure that incumbent settings object is correctly defined. This closes #167 by finally implementing the plan in #167 (comment) for making the correspondences clear.
This adds a new section under scripts detailing the entry, incumbent, current, and relevant concepts with regard to realms/global objects/ environment settings objects. This centralizes information that was previously somewhat spread out, and adds lots of details, as well as an example. This takes care of some of the pain points noted in #473, in particular fixing the definition of entry settings object to be more clearly defined in terms of the JavaScript execution context stack. There is still some work to do in that issue: namely, updating Web IDL with regard to tracking the entry settings object, and also making sure that incumbent settings object is correctly defined. This closes #167 by finally implementing the plan in #167 (comment) for making the correspondences clear.
This adds a new section under scripts detailing the entry, incumbent, current, and relevant concepts with regard to realms/global objects/ environment settings objects. This centralizes information that was previously somewhat spread out, and adds lots of details, as well as an example. This takes care of some of the pain points noted in #473, in particular fixing the definition of entry settings object to be more clearly defined in terms of the JavaScript execution context stack. There is still some work to do in that issue: namely, updating Web IDL with regard to tracking the entry settings object, and also making sure that incumbent settings object is correctly defined. This closes #167 by finally implementing the plan in #167 (comment) for making the correspondences clear.
As I understand it the reason we have a distinction here is because at some point JavaScript might have a competing language and it is considered unclean (by some) to tie HTML directly to JavaScript.
However, as long as that language is not there (and it seems a long way off, if ever, even wasm will reuse the VM), the current standard is unnecessarily confusing and complicated. It would be much simpler if we made the environment settings object bits internal slots of the global object.
Just as the HTML parser uses the DOM with the caveat that implementations may pick their own tree model, the HTML Standard should use JavaScript and its global object. Implementations of the HTML Standard that have a different language can adapt, just as HTML parser implementations can.
The text was updated successfully, but these errors were encountered: