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

Yep, this sounds reasonable; suspending in bfcache LGTM. These roughly match what I've been thinking, and great point about how `fetch`'s signal is used for more than just the network operation. A few more thoughts inline below:

> Here's was my thought process on the pros/cons of suspending:
> 
> * (+) Matches setTimeout() so might be more expected for developers

Note: this is unfortunately [broken in  in Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=1202687), but I do like the consistency.

> * (+) Easier to spec and probably easier to implement
> * (+/-) Avoids "timer storms" upon reactivation
> * (-? but not really) Seemingly doesn't match the primary use case that well, of erroring an operation if it took too long. E.g. if you use `fetch(..., { signal: AbortSignal.timeout(30_000) })`, and the server still hasn't responded after 30 seconds, you don't care whether some of those 30 seconds were spent in bfcache: the server is probably not going to respond.
>   
>   * This is why the "timer storms" argument is both a pro and a con: having a bunch of stuff get aborted upon bfcache restore, because it took too long, actually seems OK! It's very different than _running a bunch of code_ upon bfcache restore, which is what you would expect with `setTimeout()`.

Yeah aborting stuff on restore would be good in this scenario, although timer storms could still result if these signals have `abort` event listeners that do a bunch of work in response to the error.

>   * On the other hand, I believe this scenario isn't realistic: if you go into bfcache, I'm pretty sure all ongoing fetches will be aborted immediately anyway. (Or maybe we just won't let you go into bfcache with ongoing fetches; not sure.)

We're [recommending](https://web.dev/bfcache/#always-close-open-connections-before-the-user-navigates-away) that devs close connections in `pagehide`, and that article is leading me to believe pages with ongoing fetches aren't eligible for bfcache in Chromium. I'm not sure about other browsers.

Combining a timeout signal with one that gets aborted on `pagehide` seems like maybe a good option? If we can make it more ergonomic to combine signals that would be even better. (Although, you might get into scenarios where you have the data but end up aborting the processing like you're describing below.)

>   * Finally, what really swung this for me was remembering that we use `fetch()`'s `signal` for more than just the network operation: we use it for, e.g., JSON decoding or other consume-body operations. So consider the scenario where the server responds, and perhaps even all of the body is read into memory. But then we go into bfcache, before the promise returned from `json()` can fulfill. If we spend a minute in bfcache and then go back, we don't really want the promise to reject; we want it to do that last tiny bit of work, and fulfill! I think this is probably a specific case of a more general scenario, possibly involving non-browser APIs that use `AbortSignal` and care about timeouts.

-- 
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#issuecomment-977032934