Beacon is only exposed to Worker in Microsoft Edge

[toddreifsteck]

Our tests at https://github.com/w3c/web-platform-tests/pull/4024 show that Worker is only exposed in Microsoft Edge. It seems like perhaps it should be limited to Window.

[igrigorik]

https://github.com/w3c/beacon/commit/ad3cf91ca66fb3dccc926233dfa7185aa47eda0e#diff-eacf331f0ffc35d4b482f1d15a887d3bR274 defined sendBeacon on WorkerNavigator. However, it does appear that neither Chrome nor FF implemented it... wish we caught that earlier!

It seems like perhaps it should be limited to Window.

I'm inclined to agree... One of the primary reasons for sendBeacon is/was to remove the need for synchronous requests blocking the UI thread. If you're running code within a worker, then you've already taken the necessary precautions against that. Also, now that we've landed keepalive flag for Fetch, worker code can leverage (once implemented :)) same semantics as sendBeacon but with added flexibility of customizing the request method, headers, etc.

In other words, exposing sendBeacon on Worker at this point is, at best, a convenience wrapper on Fetch, and I'm inclined to say that it's not worth it; we're better off nudging developers to work with Fetch API moving forward... both within Worker and Window.

@annevk @bzbarsky any thoughts or objections?

[bzbarsky]

However, it does appear that neither Chrome nor FF implemented it...

Firefox's implementation of sendBeacon was written before the WorkerNavigator addition, and no one bothered to file bugs on implementations when the spec was changed, apparently. :(

I don't know enough about the persistence flag on fetch to comment on the rest. Does it allow a worker to create a fetch that outlives the worker?

[annevk]

@igrigorik sounds good.

@bzbarsky yeah, the keepalive flag would allow for that.

[igrigorik]

@toddreifsteck @annevk removed in 95e6a1f, closing.