So this is kind of interesting, and I had a look at the spec.
> The data parameter is the BodyInit data that is to be transmitted.
However I couldn't find any information in the Spec itself about the size of the data until it said this :
> The user agent imposes limits on the amount of data that can be sent via this API: [...] If the amount of data to be queued exceeds the user agent limit [...] , this method returns false; a return value of true implies the browser has queued the data for transfer. However, since the actual data transfer happens asynchronously, this method does not provide any information whether the data transfer has succeeded or not.
Am I missing something or does this seem as unreliable as any other method for achieving this ?
How about, and this might be a crazy idea, letting the users leave without annoying them ?
Technically speaking a conforming agent can ignore every single sendBeacon call by always returning false. And that's a point: beacons are opportunistic asynchronous requests. You can't do anything when they error anyway, so they should be regarded as hints that agents may or may not honor.
Okay so it's basically just a baked in implementation of what people did already but instead of using onUnload they have more visibility into the client context. Seems dirty in a way, the agent could basically internally call the same thing and send any data to their own server on every page?
For example, firefox, If they wanted, could record all your browsing history without notifying you? For any bad actor this seems like an amazing attack point.
You may not want to rely too much on `beforeunload` events though as it is unreliable on mobile, a good practice if you want to send analytics if to listen to the page visibility:
This is neat, but don't service-workers persist for like 5s (non-deterministic) before being unloaded?
>Sometimes we want to send a piece of data to our servers when user leaves our website or webapp.
I've never.
>Maybe it’s for for analytics or even auto-logout when they leave the website.
Just don't persist the auth token? Analytics is blocked at the DNS level anyway.
So this is kind of interesting, and I had a look at the spec.
> The data parameter is the BodyInit data that is to be transmitted.
However I couldn't find any information in the Spec itself about the size of the data until it said this :
> The user agent imposes limits on the amount of data that can be sent via this API: [...] If the amount of data to be queued exceeds the user agent limit [...] , this method returns false; a return value of true implies the browser has queued the data for transfer. However, since the actual data transfer happens asynchronously, this method does not provide any information whether the data transfer has succeeded or not.
Am I missing something or does this seem as unreliable as any other method for achieving this ?
How about, and this might be a crazy idea, letting the users leave without annoying them ?
Technically speaking a conforming agent can ignore every single sendBeacon call by always returning false. And that's a point: beacons are opportunistic asynchronous requests. You can't do anything when they error anyway, so they should be regarded as hints that agents may or may not honor.
Okay so it's basically just a baked in implementation of what people did already but instead of using onUnload they have more visibility into the client context. Seems dirty in a way, the agent could basically internally call the same thing and send any data to their own server on every page?
For example, firefox, If they wanted, could record all your browsing history without notifying you? For any bad actor this seems like an amazing attack point.
You may not want to rely too much on `beforeunload` events though as it is unreliable on mobile, a good practice if you want to send analytics if to listen to the page visibility:
Of course it can't strictly be considered a "page leave" but for mobile users it's often your best bet: https://developer.chrome.com/docs/web-platform/page-lifecycl...If you'd like, you can also Say Bye to Say Bye with JavaScript Beacons in about:config by setting beacon.enabled to false
This would be nice but I can't see any option for Chromium/Brave inside the chrome://flags .. Do you know if there is one ?
Major hm... analytic tools... like MixPanel support this.
Where has this been hiding how did I not know about this?