Support Fetch keepalive flag and enforce limit on inflight keepalive bytes

ASSIGNED
Assigned to

Status

()

defect
P2
normal
ASSIGNED
2 years ago
3 months ago

People

(Reporter: igrigorik, Assigned: dragana, NeedInfo)

Tracking

(Blocks 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-triaged])

(Reporter)

Description

2 years ago
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

Updated

2 years ago
Component: Untriaged → DOM
Product: Firefox → Core
Priority: -- → P2
Component: DOM → DOM: Networking
Priority: P2 → --
(Assignee)

Comment 1

6 months ago
Andrew, how urgent is this? is it still a P2?
Flags: needinfo?(overholt)
I'll defer to asuth on priority since I'm not sure how much of a real world compat issue this is.
Flags: needinfo?(overholt) → needinfo?(bugmail)
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.
Flags: needinfo?(bugmail)
(Assignee)

Comment 4

6 months ago
Ok, thanks.
Priority: -- → P2
Whiteboard: [necko-triaged]
Dragana - can you take this on?
Assignee: nobody → dd.mozilla
Flags: needinfo?(dd.mozilla)

Comment 6

4 months ago
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.