Re: [whatwg/fetch] Deferred fetching (PR #1647)

@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;

This is tricky because the page may be frozen after visibilitychange and no JS timers will fire I think there is a footgun here. Browsers may suspend JS timers after visibilitychange. Explicitly, this happens on the `freeze` event but I suspect it might happen at other times too (`freeze` is experimental and [not available in](https://caniuse.com/mdn-api_document_freeze_event) WebKit or Mozilla, I think).

So that makes it maybe impossible reliably implement send-after-hidden (if some browsers stop timers). Even in those that send a `freeze` event before stopping timers, it's complex to get correct, you need to

- set a timer
- listen to freeze
- if either happens, send the beacon immediately and prevent the other event handler from doing so. E.g.

So we may need to give users a way to set a timeout after hidden. Maybe a way to say "timeout after JS timers become unreliable" covers this and BFCache?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1647#discussion_r1197440171
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1647/review/1432106496@github.com>