`url` is never interpreted as `null`/`undefined`

[mingyc]

As mentioned in https://github.com/WICG/pending-beacon/issues/17#issuecomment-1202101055, the URL that Pending*Beacon(url) constructor or setURL(url) gets are always parsed into string literal, even if its value is null or undefined, i.e. they get converted to 'null' or 'undefined'. The URL constructed then becomes https://example.com/null for beacons on https://example.com.

This behavior is caused by the IDL definition that inherits from navigator.sendBeacon():

boolean sendBeacon(USVString url, ...);

interface PendingGetBeacon : PendingBeacon {
  constructor(USVString url, ...);
  void setURL(USVString url);
};

USVString should be USVString? to allow null/undefined values.

I guess the original intention is to make url non-optional. But converting null to string just seems wrong. We are also unsure about how many users rely on this behavior when using navigator.sendBeacon().

In PendingBeacon's case, there is a discussion around whether to allow constructing a beacon first (without an explicit URL), and updating its URL later. The current API is already kinds of supporting this behavior with setURL(), except that when users trying to construct one with url=null, they gets an unexpected https://example.com/null instead.

To update PendingBeacon to not have this behavior, the explainer also needs to specify one of the following options:

1. The browser must not send out beacons without a URL set.
2. OR Pending*Beacon() throws TypeError on getting null/undefined URL.