Review pass

Author: mgaudet

README.md

@@ -28,7 +28,7 @@ unexpected.
 ## Why is this a problem?
 
 The most concrete one is security vulnerabilities. We must be ever-vigilant about
-this compatability supporting feature in all standard work, and throughout
+this compatibility supporting feature in all standard work, and throughout
 the web-platform. Failure to do so has the consequence of possible exploitation:
 
 - [CVE-2024-43357](https://github.com/tc39/ecma262/security/advisories/GHSA-g38c-wh3c-5h9r) on the specification.
@@ -37,9 +37,9 @@ the web-platform. Failure to do so has the consequence of possible exploitation:
 - [CVE-2024-9086](https://www.welivesecurity.com/en/eset-research/romcom-exploits-firefox-and-windows-zero-days-in-the-wild/)
 - Others not disclosed here. 
 
-The reason this particular issue is fingered for causing security vulnerabities is
+The reason this particular issue is fingered for causing security vulnerabilities is
 that it adds many paths for user code execution which otherwise don't exist, and
-is not always obviously a possbility.
+is not always obviously a possibility.
 
 Of particular danger is where specification authors think of newborn objects of known
 types as known quantities, only to call `Promise.resolve` on them. At this point
@@ -51,22 +51,23 @@ exist purely to work out the expected behaviour [for someone breaking `then`](ht
 
 ## How do I propose we fix this?
 
-I'd like to propose we add a "Safe Resolve" resolve operation. It is functionally identical to
-[`PromiseResolve`](https://tc39.es/ecma262/#sec-promise-resolve) except there is a pre-step where
-we check for the conditions under which we could run user-code. If we cannot run any user code, we simply
-tail-call into `PromiseResolve`. If we *could* run user-code, we instead enqueue a new job whose
-responsibility is to call into `PromiseResolve`, while also putting the promise into a 'parked' state
-such that any future resolutions are ignored (Thank you very much to Mark Miller for catching this
-requirement in TG3 review discussion).
+I'd like to propose we add a "SafeResolve" resolve operation, which resolves a promise after
+checking for the possibility of running user code.  If we cannot run any user code, we simply
+tail-call into the promise capability's `[[Resolve]]` operation. If we *could* run user-code,
+we instead enqueue a new job whose responsibility is to resolve the promise while also latching
+the promise in the same way the regular resolve functions do, such that any future resolutions
+are ignored (Thank you very much to Mark Miller for catching this requirement in TG3 review discussion).
 
 The next step is to decide how to consume this. There is interest from the Mozilla DOM to explore
 using this to replace [the steps for resolving a promise in WebIDL](https://webidl.spec.whatwg.org/#resolve)
 and more generally powering all the promise resolution code in Mozilla's DOM. This would help make
 C++ code safer by making promise resolution into an operation that never runs script, which
 simplifies the reasoning required when implementing code.
 
-Exposing this to user-code is a non-goal of this specific proposal, but can be done as a followup
-proposal eventually
+Specification discussion about WebIDL consumption is happening at  [whatwg/webidl #1584](https://github.com/whatwg/webidl/issues/1584)
+
+**Exposing this to user-code is a non-goal of this specific proposal**, but can be done as a followup
+proposal eventually.
 
 ## Is this a bulletproof fix?
 
@@ -108,7 +109,7 @@ The vast majority of tests (as expected) pass.
 
 #### Unexpected Pass:
 
-1. [/fetch/api/response/response-body-read-task-handling.html](https://searchfox.org/firefox-main/source/testing/web-platform/tests/fetch/api/response/response-body-read-task-handling.html) \- This test is using `then` to get insight into execution order. The test no longer tests what it thinks it is testing anymore; however the test \-also- was created to address [this kind of thennable issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1612308).
+1. [/fetch/api/response/response-body-read-task-handling.html](https://searchfox.org/firefox-main/source/testing/web-platform/tests/fetch/api/response/response-body-read-task-handling.html) \- This test is using `then` to get insight into execution order. The test no longer tests what it thinks it is testing anymore; however the test \-also- was created to address [this kind of thenable issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1612308).
 
 #### Test Failures
 

spec.emu

@@ -4,8 +4,8 @@
 <script src="./spec.js"></script>
 <pre class="metadata">
 title: SafePromiseResolve
-stage: 1
-contributors: Matthew Gaudet
+stage: 2
+contributors: Matthew Gaudet, Justin Ridgewell
 </pre>
 
 <emu-clause id="sec-safe-resolve-promise">
@@ -107,9 +107,6 @@ contributors: Matthew Gaudet
       1. Perform HostEnqueuePromiseJob(_job_.[[Job]], _job_.[[Realm]]).
       1. Return ~unused~.
     </emu-alg>
-    <emu-note>
-      <p>This overlaps heavily with the Abstract Closure inside CreateResolvingFunctions. Later work could resolve this duplication</p>
-    </emu-note>
   </emu-clause>
 
   <emu-clause id="sec-newpromiseresolvethenablejob" type="abstract operation" oldids="sec-promiseresolvethenablejob">
@@ -147,7 +144,7 @@ contributors: Matthew Gaudet
         _promiseToResolve_: a Promise,
         _thenable_: an Object,
         _then_: a JobCallback Record or a function object,
-      ): either a normal completion containing *undefined* or a throw completion
+      ): either a normal completion containing an ECMAScript language value or a throw completion
     </h1>
     <dl class="header">
     </dl>
@@ -175,7 +172,7 @@ contributors: Matthew Gaudet
     </dl>
     <emu-alg>
       1. Let _promiseOrEmpty_ be the Record { [[Value]]: _toResolve_ }.
-      1. Let _resolveSteps_ be a new Abstract Closure with parameters (_resolution_<ins>, _doSafeResolve_</ins>) that captures _promiseOrEmpty_ and performs the following steps when called:
+      1. Let _resolveSteps_ be a new Abstract Closure with parameters (_resolution_) that captures _promiseOrEmpty_ and performs the following steps when called:
         1. If _promiseOrEmpty_.[[Value]] is ~empty~, return *undefined*.
         1. Let _promise_ be _promiseOrEmpty_.[[Value]].
         1. Set _promiseOrEmpty_.[[Value]] to ~empty~.