[whatwg/dom] Introduce AbortSignal.timeout() (PR #1032)

Closes #951.

<!--
Thank you for contributing to the DOM Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.
-->

- [ ] At least two implementers are interested (and none opposed):
   * [Chromium](https://github.com/whatwg/dom/issues/951#issuecomment-785432044)
   * Gecko, I think? @annevk to confirm
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * TODO
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chrome: […](https://bugs.chromium.org/p/chromium/issues/detail?id=1181925)
   * Firefox: TODO
   * Safari: TODO

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

----

Subtle things to deal with:

* Need to export "timer task source" from HTML
* What portions of the delay logic from [setTimeout](https://html.spec.whatwg.org/#timer-initialisation-steps) and [postTask](https://wicg.github.io/scheduling-apis/#schedule-a-posttask-task) should we port over here?
  * I so far ported: wait milliseconds; ensure ordering within a global; and allow implementation-defined extra waiting (e.g. to align on CPU wakeups or allow throttling while in the background).
  * I'm on the fence as to whether we should port suspending the timer while the document is in bfcache or the worker is suspended. For e.g. fetch timeouts, it doesn't seem to matter much whether you were in bfcache/suspended; if the server took 30 wall-clock seconds to respond, you probably want to give up. On the other hand, it might be strange (or hard to implement) for this timer mechanism to behave differently from others on the platform.
  * Should these timers impact [idle callback deadline computation](https://html.spec.whatwg.org/#event-loop-processing-model:map-of-active-timers)? postTask timers do not, but that may be an oversight. @shaseley @noamr
  * I think that, like postTask, we should not port the nesting and clamping messiness from setTimeout. The implementation-defined extra time is enough.
* Probably it's time to centralize this delay logic so that this spec, HTML, and postTask can reuse it. But we'd need to decide on the above questions first.
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/dom/pull/1032


-- Commit Summary --

  * Introduce AbortSignal.timeout()

-- File Changes --

    M dom.bs (38)

-- Patch Links --

https://github.com/whatwg/dom/pull/1032.patch

https://github.com/whatwg/dom/pull/1032.diff


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1032