Re: [whatwg/dom] Add AbortSignal.timeout(ms) (#951)

> Does this mean that I should just internally call setTimeout?

Nah, I meant it should use the [timer task source](https://html.spec.whatwg.org/#timer-task-source) as opposed to some other task source. In Blink it looks like this means using either [kJavascriptTimerImmediate or kJavascriptTimerDelayedLowNesting](https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/public/platform/task_type.h;l=78;drc=5d00f1fb076a71d27719cd00f2bf1066e4909fc7).

In practice the intention here is that it should have the same "priority" as setTimeout (which is generally relatively low, below important thinks like user interaction).

> What is the clamping/nesting behavior?

Per [spec](https://html.spec.whatwg.org/#timer-initialisation-steps) steps 11-12, if you nest setTimeout() calls 5 times, then any timeout value <= 4 ms gets clamped to 4 ms.

In implementations, I think things are a bit different, e.g. I believe Chrome always clamps 0 ms to 1 ms, and we also have other minor bugs like https://crbug.com/1108877. [See the code for more](https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/frame/dom_timer.cc;l=88;drc=61219381be5d2405dcd1aac31fc60eaf6342896a). I'm basically saying, let's try to bypass that non-interoperable mess, and just always respect the timeout that the web developer passes.

The argument for applying the same clamping to `AbortSignal.timeout()` would be that the clamping is in place for a sort-of-good reason, and letting people use `AbortSignal.timeout(ms).addEventListener("abort", fn)` as a non-clamped version of `setTimeout(ms, fn)` could be bad. But I don't fully buy that. People bypass the clamping already using [tricks](https://github.com/YuzuJS/setImmediate#the-tricks), so IMO the clamping is more about legacy compatibility at this point.

Note that this per-spec clamping is separate from any user agent policy decisions like throttling or aligning background timers. `AbortSignal.timeout()` should still be subject to those. In practice I suspect this means just using a given implementation's existing "schedule some JavaScript in the future" functionality.

> I'm guessing this means that I just have to write it like this when I add it to the IDL?

Yep, exactly.

-- 
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/issues/951#issuecomment-785450064