Request for Mozilla Position: AbortSignal.any()

[shaseley]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: AbortSignal.any()
• Specification or proposal URL (if available): Add AbortSignal.any() whatwg/dom#1152
• Explainer URL (if available): https://github.com/shaseley/abort-signal-any
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @smaug---- (reviewer on the PR)

Other information

• Memory management
  • Composite signals (those created by this API) need to be kept alive as long as they can be aborted and have 'abort' event listeners or pending abort algorithms (the spec PR has a note about this). As part of implementing this In Chromium, we needed to make sure abort algorithms were being removed when they were longer needed, e.g. when all fetch state is GCed and the signal can no longer affect the fetch or response. See also this issue.
• Early TAG Review: Design review: AbortSignal.any() w3ctag/design-reviews#737
• Integration with Scheduling APIs
  • As mentioned in the explainer, there's a specialization for TaskSignal.any() so the returned signal also has priority. The draft spec PR is here, which mirrors the DOM PR.

[smaug----]

I think this looks very reasonable, useful small addition to an existing API.
The pr has possibly just very minor issues.
I'd say we could be positive about this.

(TaskSignal.any is then different topic, since it is still a bit unclear whether Scheduler API is useful.)