The user agent MUST initiate a fetch with keepalive flag set
This is (hopefully?) redundant with the actual processing model given for the method
, which restricts the amount of data that can be queued by such requests to ensure that beacon requests are able to complete quickly and in a timely manner.
This is not sufficiently specified in a manner that could be interoperably implemented. I think it's also redundant with the processing model step 6.2? (Which is also vague.)
The user agent MUST schedule immediate transmission of all beacon requests when the document visibilityState transitions to hidden,
This is a monkeypatch.
and must allow all such requests to run to completion without blocking other time-critical and high-priority work.
I have no idea how one would implement this.
The user agent SHOULD schedule transmission of provided data to minimize resource (CPU and network) contention with other time-critical and high priority work.
The user agent MAY delay transmission of provided data to optimize network and energy efficiency - e.g. deliver immediately if the network is active, or wait until network interface is active. However, the user agent SHOULD NOT delay transmission indefinitely and ensure that pending transmissions are periodically flushed even if there is no other network activity.
These seem like they're gesturing at Fetch's priority concept, but it should probably be done explicitly.
The section at https://w3c.github.io/beacon/#sendbeacon-method contains a variety of problematic requirements:
This is (hopefully?) redundant with the actual processing model given for the method
This is not sufficiently specified in a manner that could be interoperably implemented. I think it's also redundant with the processing model step 6.2? (Which is also vague.)
This is a monkeypatch.
I have no idea how one would implement this.
These seem like they're gesturing at Fetch's priority concept, but it should probably be done explicitly.