1342484 - (fetchKeepAlive) [meta] Support Fetch keepalive flag and enforce limit on inflight keepalive bytes

Status: NEW

(Core :: DOM: Networking, task, P2)

Description

[Ilya Grigorik]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

https://github.com/whatwg/fetch/pull/419

> Requests with keepalive flag set are allowed to outlive the environment
> settings object. We want to make sure that such requests do not
> negatively impact the user experience when a page is unloaded, etc.
> 
> This limits the amount of (body) bytes that can be inflight at any point
> when the request has the keepalive flag set; this flag is set by
> sendBeacon.



Expected results:

Firefox should support the keepalive flag & enforce the inflight byte limit.

p.s. this is also used by sendBeacon: https://github.com/w3c/beacon/pull/39

Comment 1

[Dragana Damjanovic [:dragana]]

Andrew, how urgent is this? is it still a P2?

Comment 2

[Andrew Overholt [:overholt]]

I'll defer to asuth on priority since I'm not sure how much of a real world compat issue this is.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

I think we want fetch keepalive for our next big wave of SW enhancements.  To restate the situation as I understand it from https://github.com/w3c/ServiceWorker/issues/1336 and others, as well as the ServiceWorker F2F at TPAC is:
- navigator.sendBeacon() is not exposed in ServiceWorkers because the idea was fetch keepalive is the underlying primitive and we should expose just that.
- There is interest from various large sites to be able to send reliable beacons without doing things that would impact the performance of the SW because of concerns about premature SW termination if not protected by a waitUntil.  (In particular, the activation step.)
  - This is of somewhat extra importance given that large sites in particular seem to want to have a panic button that lets them turn off ServiceWorkers across their site based on metrics, etc. and beacons are an important part of their metrics about whether they need to panic or not.  (Clear-Site-Data does help here, but the UX of Clear-Site-Data means that sites are likely to only want to use that as a last resort.)

P2 sounds reasonable to me, but I don't know what the P2's are it's competing with.  It's definitely something that should have an ETA in 2019Q1 or Q2.

Comment 4

[Dragana Damjanovic [:dragana]]

Ok, thanks.

Comment 5

[Selena Deckelmann :selenamarie :selena]

Dragana - can you take this on?

Comment 6

[Anne (:annevk)]

I forgot to update this, but we discussed this and no longer think the currently specified keepalive limit makes sense: https://github.com/whatwg/fetch/issues/679.

What would work well for Safari and us (at least per current anti-tracking strategy) is to have a limit on number of keepalive fetches (not necessarily the amount of bytes, but we if count bytes it needs to count headers too) per first-party origin.

Comment 7

[asa.kusuma]

Another use case for fetch keepalive is the ability to handle server errors and allow outliving the environment, without the use of a service worker. Although you can't handle server errors for a request that outlives the environment (without a service worker), it would be nice to have a single API that could handle either scenario (server error OR outlive environment), albeit not at the same time.

Comment 9

[Andrei]

Hi there, any update on this issue?
The problem is that some adblockers have started blocking Beacon requests so keepalive flag is even more important now.

Comment 10

[csvn.dev]

I'm also very interested in support for this feature. If you discount IE, Firefox is the only browser without support for the keepalive flag since 2019: https://caniuse.com/mdn-api_request_keepalive

My use case:
We're sending metadata to a server, and we want to be certain it's sent even if the page is being unloaded. We don't really care about it's body, but we need to know when the request is complete. Navigator.sendBeacon() supports the former, but not the latter (since we don't get a promise back). Using fetch with keepalive: true ensures both conditions; not being canceled as well as receiving a promise back for when the request is complete.

We can't replace our current Navigator.sendBeacon() usage completely, since Firefox does not support fetch with the keepalive flag. It would be great for Web compatability if this feature was implemented.

Comment 11

[d.shovchko]

Hey guys! Is there any hope that we will ever be able to use this feature in Firefox?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

This would require some reverse engineering to have something compatible with the other browsers (see https://github.com/whatwg/fetch/issues/679), but what is in the spec, https://fetch.spec.whatwg.org, is rather simple.
Valentin, do we already support keepalive type of requests from Necko point of view - requests which stay alive a bit longer than the relevant browsing context or window context?

Though, we would still want to have some keepalive manager in the parent process to limit the number of such requests per origin or so.
Or perhaps something simple like what sendBeacon does would work reasonable well too, one could add a shutdown blocker or some such for the relevant content process.

Comment 13

[Valentin Gosu [:valentin] (he/him)]

I think there are two relevant mechanisms here.

1. The load group. I think fetch requests go in the loadgroup of the page it's created from, so when that gets unloaded, fetch requests would get cancelled. I think it is definitely possible to have a different loadgroup for keepalive requests, so we don't cancel them on unload.
2. The channel actors. PHttpChannel is managed by PNecko which is managed by PContent. If the user closes the tab and that destroys PContent, the channels should also get destroyed. Though I'm not 100% sure that is what we do right now. Right now, the signal to close the channel when the tab dies is sent from HttpChannelChild::ActorDestroy so it should be easy to exclude keepalive requests.

A keepalive channel manager would indeed be necessary to enforce the limits and make sure we properly clean up after the channels.

Comment 14

[Anastasiya]

Hi, everyone! It will be perfect to have this feature in Firefoxe)

Comment 15

[Gernot Raudner]

any updates to this? keepalive is living standard, and firefox already implements a very similar approach with sendBeacon. so i think this should be a rather low-hanging fruit?

Comment 16

[Andrei Anischevici]

+1 Please fix this

Comment 17

[lena.a.cohen]

Hi! Any updates on when the keepalive flag will be supported in Firefox? I can't use sendBeacon for my application because I need to set custom headers, and fetch with keepalive is the only alternative.

Comment 18

[Sunil Mayya]

(In reply to lena.a.cohen from comment #17)

Hi! Any updates on when the keepalive flag will be supported in Firefox? I can't use sendBeacon for my application because I need to set custom headers, and fetch with keepalive is the only alternative.

Hello Lena,
We have started the implementation for keepalive. You should expect this to be operational within next two releases.

Comment 19

[lena.a.cohen]

(In reply to Sunil Mayya from comment #18)

(In reply to lena.a.cohen from comment #17)

Hi! Any updates on when the keepalive flag will be supported in Firefox? I can't use sendBeacon for my application because I need to set custom headers, and fetch with keepalive is the only alternative.

Hello Lena,
We have started the implementation for keepalive. You should expect this to be operational within next two releases.

Thank you so much Sunil!

Comment 20

[Alex Arriaga]

Hi Sunil/Firefox team,

Do we have any insights about Firefox versions where we could potentially have keepalive fully supported? Is it around Firefox v128?

Best regards.

Comment 21

[ivan.sieder]

(In reply to Sunil Mayya from comment #18)

(In reply to lena.a.cohen from comment #17)

Hi! Any updates on when the keepalive flag will be supported in Firefox? I can't use sendBeacon for my application because I need to set custom headers, and fetch with keepalive is the only alternative.

Hello Lena,
We have started the implementation for keepalive. You should expect this to be operational within next two releases.

In the meantime 3 additional versions had been releases, is there any kind of roadmap until when this can be expected to land in stable firefox?

Comment 22

[Sunil Mayya]

Hello Lena, Ivan, Alex
Thank you for checking on this and sorry for the delay

Last week, I merged the initial implementation for the keepalive feature based on the fetch specification, which should now work for non-worker fetch requests. This feature is available for initial testing in this week's nightly build and in the official 129 release next month.

As the feature is disabled by default due to some pending work on workers, you can enable it by setting "dom.fetchKeepalive.enabled" in about:config.

I would greatly appreciate your feedback on this feature. Your insights and testing results will help me refine it sooner.

Thank you for your support.

As far as the official version, you can expect it to be fully functional around 130-131.

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.