Deferred fetching feedback

[annevk]

Feedback on #1647 to keep the overall PR in terms of comments and such somewhat smaller in size.

• Put the new method under the existing "Fetch method" heading, but rename it to "Fetch methods". "Fetch" in this heading is not a reference to fetch(), but to the fact that the method can fetch. So "FetchLater method" doesn't make a whole lot of sense in that light.
• FetchLaterResult needs to be [Exposed].
• User agent is without hyphen, see Infra.
• "Not allowed in this context" is woefully vague. Can we do better or even agree on a model here?
• If the exceptions are meant to be DOMException that should follow the style for them.
• "This may throw an exception." we generally don't state this.
• "If request’s URL is not a potentially trustworthy url," This is a Mixed Content consideration and should be caught by the network layer, not the API.
• "exists then" missing comma.
• "DOMHighResTimeStamp then" missing comma.
• "0 then" missing comma.
• I would put an <hr> before the deferred fetch record definition.
• Why are some request body checks made inside fetchLater() and some inside "request a deferred fetch"?
• "The user agent may process deferred fetches at any given moment" This seems wrong? I suppose it's only when the browser expects that the fetch groups will die? (Unfortunately fetch groups are not well-defined...)
• "process deferred fetches for fetchGroup." needs uppercase P at the start.

[noamr]

"If request’s URL is not a potentially trustworthy url," This is a Mixed Content consideration and should be caught by the network layer, not the API.

How do I do that synchronously? I basically want to allow only HTTPS+localhost-ish and throw immediately if that's not the case.

[noamr]

... Fixed everything else.

[noamr]

Regarding activationTimeout:

• Usually timeouts mean "no earlier than" (e.g. setTimeout), while here we mean "no later than", which is more of a deadline.
• Deadline sounds a bit rigid, because here the browser can still delay further than the deadline.

Suggesting dueAfter or activationDelay but open to other suggestions.

[annevk]

How about activationBefore? Nicely complements fetchLater.

Let me also copy in @domenic as the person having last touched timers in HTML and likely having relevant opinions.

[noamr]

How about activationBefore? Nicely complements fetchLater.

Actually it would be activateAfter rather than before.
"Fetch later, but activate after X ms" sounds like the right story-ish.

[noamr]

[copying from Matrix]

The reason why I like activateAfter:

The fetch could be activated after the deadline or before, but for different reasons. The timeout duration is like a preference. The UA would activate before the timeout in case of termination or some such, and after the activation timeout for throttling/batching.

The word "timeout" is maybe confusing because it's the opposite of the abort signal's timeout
So activateAfter means the same as activationTimeout but it's clearer that it's "a timeout after which activation should take place" rather than "A timeout after which activation expires" or something like that.

/cc @smaug---- @mingyc @fergald

[domenic]

I was asked to provide feedback but since I have been purposefully not paying attention to the giant thread #1647, I don't have much to provide. For example I have no idea what "activation" or "activate" concept is being discussed.

I'm happy to leave this to my colleagues, as I don't think the value I can provide here is outweighed by the amount of time it would take me to get up to speed on this API.

[noamr]

"Not allowed in this context" is woefully vague. Can we do better or even agree on a model here?"

I think this is the main remaining issue. @mingyc what is the model for this in chromium? Do we use the backgorund-fetch permission?

[mingyc]

If the user agent has determined that deferred fetching is not allowed in this context, then throw a NotAllowedError .

what is the model for this in chromium? Do we use the backgorund-fetch permission?

I thought we should use permission policy as described in WICG/pending-beacon#77. The proposal is by default it should be enabled. It is currently not implemented in chromium though.

Unrelated to this topic, but background-sync permission is used to tell if a pending deferred fetch request can still be pending after navigating away from a page (in bfached). See also WICG/pending-beacon#3 (comment)

[mingyc]

f the user agent has determined that deferred fetching is not allowed in this context, then throw a NotAllowedError .

After some offline discussions, we think it's fine to remove this check for now, as there is currently no permissions policy defined for other keepalive requests (fetch, sendBeacon()).

We we get more feedback about providing control on this, the policy should be implemented not just for FetchLater, but for other keepalive requests.

[noamr]

OK, as discussed at TPAC, sending a NotAllowedError for contexts that are cross-origin from the top-level (e.g. 3p iframes), but not requiring a particular permission. I think all the checkboxes are complete now.

[fergald]

Is there some record of the TPAC discussion? I don't understand why we would ever deny a call to fetchLater when the frame can use fetch with/without keep-alive or sendBeacon. This just seems like it will push people away from using this and they will use something that is worse for users (e.g. sending immediately).

If someone wants to propose a permissions policy that controls all keep-alive-like fetches, that would be consistent. I would also want to understand why that would be desirable.

[noamr]

Is there some record of the TPAC discussion? I don't understand why we would ever deny a call to fetchLater when the frame can use fetch with/without keep-alive or sendBeacon. This just seems like it will push people away from using this and they will use something that is worse for users (e.g. sending immediately).

If someone wants to propose a permissions policy that controls all keep-alive-like fetches, that would be consistent. I would also want to understand why that would be desirable.

It's here, though I didn't participate in this discussion.