- From: fergald <notifications@github.com>
- Date: Fri, 19 May 2023 00:40:13 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/1647/review/1433936810@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 = {}); Saying that we will run these tasks before everything else is concerning. Up until now, no JS runs between `pagehide` and `visibilitychanged` (surprisigly`visibilitychanged` fires before `pagehide` *and* before `pageshow`). Giving these promise resolutions special priority doesn't seem right. What if another feature also requires special priority to run before veverything else? It also doesn't solve the problem when there are 2+ of them. I would hope that people don't put complex code into these resolve callbacks such that it might look at another pending fetch but any amount of work, including updating logged data, can be hidden behind some framework's function call. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/1647#discussion_r1198647592 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/pull/1647/review/1433936810@github.com>
Received on Friday, 19 May 2023 07:40:18 UTC