Re: [whatwg/webidl] Record timing info for promise resolve/reject and callback (PR #1400)

Example 1:
```js
fetch(url).then(() => { ... })
```

If `fetch` returns a promise that will be resolved later, the `resolve` would be the entry point.
If `fetch` returns a resolved promise, then the script entry point is whoever called `fetch`, and that script execution continues (with an additional microtask)

Example 2:
```js
// This might return an already resolved promise
const text = response.text()

setTimeout(() => do_something_with(await text))
```

If `text` returns a resolved promise here it doesn't trigger a user script. We have to have an extra author script that reacts to the promise. The point is that there's always a script that reacts to a resolved promise.

> A thing I don't understand is that promise resolution isn't a guarantee that script will run.

True, the worth that can happen though is that a promise resolution that takes as long time would be counted as if it was an author script.

> And there's also no guarantee that when a specification calls resolve/reject the JS stack is empty.

Those checks are done inside the Long Animation Frame timing spec. If there is already a running entry point, we return early (see https://w3c.github.io/long-animation-frames/#create-script-entry-point #6). The end point is anyway called directly from HTML [here](https://html.spec.whatwg.org/multipage/webappapis.html#perform-a-microtask-checkpoint) when we clear the mictorask queue. 

> 
> Why isn't this done as part of HTML's script running algorithms? It seems that already has the appropriate start and end points.

The "end" point called from HTML (see above).
We call the start point from the call sites because that's where we have the metadata (e.g. that this is a promise resolver). We could do something like register the metadata somewhere and record the timing in HTML but the observable result would be very similar.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1400#issuecomment-2228534705
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1400/c2228534705@github.com>