Property updating should be atomic

[yutakahirano]

We have several properties (url, method, ...) which can be updated independently. This is not good from two reasons.

1. The user agent may start sending data while we are updating properties (see also: When the user agent sends data should be clarified #7).
2. The page may crash while updating properties.

Let's think about (2) as it's simpler.

let beacon = new PendingBeacon(url, {method, data});
...
// (p)
beacon.url = newUrl;
// (q)
beacon.method = newMethod.
// (r)
beacon.setData(newData);
// (s)

A page may crash at any timing, so with the current API the web developer need to deal with four possibilities. This can be pretty confusing, because by nature analyzing crash reports is hard and complex.

crash point	url	method	data
(p)	url	method	data
(q)	newUrl	method	data
(r)	newUrl	newMethod	data
(s)	newUrl	newMethod	newData

While (q) and (r) are rare, all can happen. For multi-process implementations such as Chrome, the possibility grows when the system is busy, because of IPC latency.

We can address this problem by making the modification atomic.

let beacon = new PendingBeacon(url, {method, data});
...
// (X)
beacon.update({url: newUrl, method: newMethod, data: newData});
// (Y)

Now we have only two possibilities.

crash point	url	method	data
(X)	url	method	data
(Y)	newUrl	newMethod	newData

[fergald]

I'm not sure that we have any use case for changing any property after construction. Unless we get a concrete request for that capability, I'd suggest that all properties should be set at construction time and immutable after that.

[yutakahirano]

Sounds reasonable, thank you!

[jdfreder]

I don't think it's to far fetched to want to update query args on the URL, for systems that still rely on query args instead of HTTP body. Additionally, I'm not convinced that we'd need an atomic operation to update multiple properties (I would expect the failures you mention in the case above, and not expect the browser to mitigate that).