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

> In previous timeout APIs (i.e., XMLHttpRequest), the caller would get to know why something was aborted. I think that's something we should consider here. Whether fetch() should reject with a plain "AbortError" DOMException or something that indicates it happened as the result of a (self-imposed) timeout.

Hmm, I see the argument. In particular, usually the caller of `fetch()` wants to ignore aborting caused by `AbortSignal`s since they indicate we don't care. (This leads to API proposals like https://github.com/heycam/webidl/issues/933.) But in reaction to a timeout, instead you might want to retry, or treat it like a network error.

This means that if we were to do fetch timeouts, we would not do them using `signal` at all, but instead would need to make them a first-class part of the fetch API. So that brings us back to https://github.com/whatwg/fetch/issues/20.

That definitely puts a damper on my enthusiasm here.

> We're trying to reduce the amount of code that executes in the background, and throttling/clamping is part of that. Wouldn't this just become a way to work around it? https://developer.chrome.com/blog/timer-throttling-in-chrome-88/

No. See my response in https://github.com/whatwg/dom/issues/951#issuecomment-785450064 where I tried to more clearly differentiate between UA-specific scheduling freedom, and the setTimeout-spec-mandated-but-not-interoperable nesting-based 5 ms clamping. 

-- 
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-786198099