- From: fergald <notifications@github.com>
- Date: Thu, 08 Jun 2023 23:44:16 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/1647/review/1471336739@github.com>
@fergald commented on this pull request. > @@ -8449,6 +8597,60 @@ with a <var>promise</var>, <var>request</var>, <var>responseObject</var>, and an </div> +<h3 id=fetch-later-method>FetchLater method</h3> + +<pre class=idl> + +dictionary DeferredRequestInit : RequestInit { + DOMHighResTimeStamp backgroundTimeout; +}; + +partial interface mixin WindowOrWorkerGlobalScope { + [NewObject] Promise<Response> fetchLater(RequestInfo input, optional DeferredRequestInit init = {}); @noamr > Perhaps this can be simplified if setting this state is still done on the document's event loop. Needs a bit of research I think if you want to phrase it in those terms then you have to say something like - when the browser wants to send the request due to timeout - it pushes a task onto the XXX event loop - when the task runs: - if the request has not yet been cancelled, `sent` is set to `true` and the request can start - if the request has already been cancelled, nothing further happens - when the browser wants to send the request due to freeing up quota allow another request to be queued - we don't worry about cancelled because if it's already cancelled we would not think about it at all - `sent` is set to `true` and the can request start - when the browser wants to send the request due to the document having been destroyed (or a crash) - the request can start XXX event loop must be one which continues processing even while in BFCache. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/1647#discussion_r1223908043 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/pull/1647/review/1471336739@github.com>
Received on Friday, 9 June 2023 06:44:22 UTC