Update ECMAScript and IDL integration #373
Conversation
domenic
added
the
do not merge yet
domenic
force-pushed
the
es-idl
branch
3 times, most recently
from
61ef881 to
8c583b3
Compare
|
I have pushed two more commits to this branch, which bring us up to date with ES's initialization scheme. I have not yet done script execution, although that is next. |
domenic
removed
the
do not merge yet
There was a problem hiding this comment.
Does not remove precision? Note that XMLHttpRequest and maybe other specifications use similar language to distinguish the global environments. Perhaps "in a window" and "in a worker" need to become defined terms?
There was a problem hiding this comment.
Did you see the commit message? "The "JavaScript global environment" concept was hackily removed." etc. etc.
There was a problem hiding this comment.
I did not, but the justification does not account for usage in other standards, which I brought up in my comment.
There was a problem hiding this comment.
I think what these APIs are doing is quite bad, as noted in the linked bugs. It'd be better if other APIs used incumbent or entry settings object.
There was a problem hiding this comment.
Hmm, file a bug against https://xhr.spec.whatwg.org/ then? Not sure if this is used elsewhere. @mikewest is using the JavaScript global environment concept maybe?
|
Comments addressed; filing bug on XHR to get rid of JavaScript global environment there too. |
This updates all ES references to point to the latest specification, with links instead of section numbers. It also straightens out some type confusion between Web IDL and ES types.
This reorganizes the section on browsing context creation so that creating a browsing context is now spelled out as a series of steps, and is more explicit about the association and creation of Window, Document, and WindowProxy objects. This is part of the plan noted in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981 for integration with the new ECMAScript initialization lifecycle.
Points of note: - ECMAScript now has the appropriate hooks (as of tc39/ecma262#226) for a separate global this value and global object, allowing us to fix a long-standing willful violation. - Worker initialization was refactored extensively, to avoid creating WorkerGlobalScope objects before the corresponding realm was created. (The existing setup had the problem where it was creating a WorkerGlobalScope, derived from Object, in a thread that didn't even exist yet.) - The "JavaScript global environment" concept was hackily removed. As discussed in #380 and #382, the only uses of "JavaScript global environment" are for a couple of canvas-related concepts which need to be removed anyway. And the definition we were using did not line up very well with ES's. We temporarily replace them with vague phrasing "lives in a window" and "lives in a worker"; this is OK since those sections will be deleted soon. This fixes #380 and fixes #382. This is roughly steps 3, 4, and 6 of https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981. It contains all the changes necessary to integrate with ES's new initialization mechanisms for a given host-defined realm, without yet any of the changes for script execution. This also fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=27419.
This updates all ES references to point to the latest specification, with links instead of section numbers. It also straightens out some type confusion between Web IDL and ES types.
This relies on tc39/ecma262#226 and so isn't ready to be merged yet, but is ready to be reviewed. There will be a couple broken links into the ES spec.
I accidentally committed this to master, FYI; I reverted it since it definitely needs review, and the ES PR isn't merged yet anyway. Oops.