Skip to content

Don't require hosts to handle the FinalizationRegistry context#150

Draft
andreubotella wants to merge 1 commit into
masterfrom
finalization-registry-handling
Draft

Don't require hosts to handle the FinalizationRegistry context#150
andreubotella wants to merge 1 commit into
masterfrom
finalization-registry-handling

Conversation

@andreubotella
Copy link
Copy Markdown
Member

We currently require the HostEnqueueFinalizationRegistryCleanupJob host hook to set the FinalizationRegistry's AsyncContext mapping in order for the FR callback to be called in the right context. However, the only reason we are doing this, rather than swapping the context in CleanupFinalizationRegistry, is because if we do that, hosts might not have any context information to report for any exceptions thrown from userland JS.

However, given that we seem to be moving away from making hosts propagate the error context to error events and into storing the context whenever an Error instance is created (see #145 and #148), there's no longer any reason to make hosts handle the FR context. So this patch instead changes CleanupFinalizationRegistry to handle it.

We currently require the `HostEnqueueFinalizationRegistryCleanupJob`
host hook to set the `FinalizationRegistry`'s AsyncContext mapping in
order for the FR callback to be called in the right context. However,
the only reason we are doing this, rather than swapping the context in
`CleanupFinalizationRegistry`, is because if we do that, hosts might
not have any context information to report for any exceptions thrown
from userland JS.

However, given that we seem to be moving away from making hosts
propagate the error context to error events and into storing the
context whenever an `Error` instance is created (see #145 and #148),
there's no longer any reason to make hosts handle the FR context. So
this patch instead changes `CleanupFinalizationRegistry` to handle it.
andreubotella added a commit to andreubotella/html that referenced this pull request Feb 11, 2026
This PR updates HTML to integrate with the TC39 AsyncContext proposal,
which allows storing state associated with an async flow of execution
in JavaScript, and preserving it across different kinds of async
continuations in both JS and the web platform.

This PR does not yet handle events, since the exact behavior of those
with AsyncContext is still pending to be fully decided. But it covers
microtasks, timers, deferred script execution, focus/blur and others.

This patch does not include any changes to the `error` and
`unhandledrejection` event handling, as well as to
`HostEnqueueFinalizationRegistryCleanupJob`. This relies on the
assumption that the changes in tc39/proposal-async-context#148 and
tc39/proposal-async-context#150 will be accepted. Otherwise, error
contexts will need to be handled in HTML.

This patch relies on PR [TODO] to define the
`[PropagatesAsyncContext]` extended attribute in WebIDL.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant