- 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