> 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 ?
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.
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
navigator.sendBeacon(...);
}
});
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.
See, this is one of those "features" that clueless PMs ask their developers to implement, not having the technical knowledge to realize that their idea is unsalvageable. My other favorite is email address "validation" with ad hoc string format checks.
I'm no frontend expert but cant you just open a websocket and when the websocket dies from the server's perspective, you have your cue to do whatever cleanup you wanted to do?
I also agree with the others here that there shouldn't really be a _need_ for this kind of feature.
If I'm not mistaken, and I very well might be, it's kind of the same, however a WS connection here may be less reliable, infact if the user has a spotty connection, when you think "That user left", in the case of a local cleanup, okay that could run on the client side, however this beacon seems to be aimed at sending data back to the server when you leave, in the case of a dropped connection, you wont be able to send the data back anyway to the server.
For this 'browser' based implementation under the hood, the browser *should* have more insight into the real intention of the users exit.
I use the beacon API in my homebuilt hit-counter. It means that even if the user navigates away before the hit is registered, the request will still have a fair chance of being received by my server.
Of course there are other ways of doing this, but who wants to muck around with service workers or websockets when there is a simple, well-supported API that does exactly what you want?
I guess caching might break that depending on cache settings. And for SPAs, it might not work as desired.
The biggest is bots - on my site (and I assume most others), legitimate requests are far, far outweighed by bots. Sometimes you can tell that they are bots but it is very common for bots to pretend to be real users. Oftentimes you can't tell from a single request but only but looking at the pattern of requests.
Some bots do take the trouble of running scripts on the page but thankfully they are in the minority so far.
Caching would certainly break the system as well, in the other direction.
I don't think it's a contrived example. It seems to be one of the main use cases. From the spec:
> The main use case for the Beacon API is to send analytics such as client-side events or session data to the server. Historically, websites have used XMLHttpRequest for this, but browsers do not guarantee to send these asynchronous requests in some circumstances (for example, if the page is about to be unloaded). To combat this, websites have resorted to various techniques, such as making the request synchronous, that have a bad effect on responsiveness. Because beacon requests are both asynchronous and guaranteed to be sent, they combine good performance characteristics and reliability.
Sure, it's a form of capitulation to advertisers, that doesn't necessarily mean that it doesn't benefit the user.
If advertisers are going to be doing that stuff no matter what, corralling them has advantages. If anything, it makes creating an extension like OP's a lot easier than playing whack-a-mole with a litany of random techniques.
Yeah, don't do either of these things. Don't log me out when I close the tab. Don't spy on me after I close the tab.
Very simple!
Maybe a small nit but it isn't spying on you after you close the tab. It is spying on you the moment you close the tab and no later.
1. it delays closing until it completes, which is a performance hit, or
2. it's performing more website specific background work when I've told the browser not to by hitting the Close Tab button.
That's all. The second option is garbage collector. Not sure why the website is entitled to execute any code when I decided to close it.
What about being logged out of a real-time chat with your friend? Wouldn't you like them to know you are no longer connected? Or do you prefer to trick them with a little green 'connected' bubble that can no longer update?
When set to true, the browser will not abort the associated request if the page that initiated it is unloaded before the request is complete. This enables a fetch() request to send analytics at the end of a session even if the user navigates away from or closes the page.
In Firefox you can disable it by beacon.enable = false.
This is tricky in JavaScript, because timers are asleep/throttled in inactive tabs: https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...
And if onbeforeleave analytics is not evil, doing stuff in inactive tabs is certainly is.
It's important to realize that key assumptions your app makes (nobody is accessing my b2b saas app from a phone) are incorrect. It's important to understand user workflows.
There are higher touch ways to do this (user research is great!), and you should let users opt out, but someone trying to improve the user experience also needs to understand how users are defying their expectations
> If the amount of data that can be queued to be sent by keepalive enabled requests is exceeded by the size of transmittedData (as defined in HTTP-network-or-cache fetch), set the return value to false and terminate these steps.
Does anyone know?
tux3•5mo ago
bilekas•5mo ago
ravenstine•5mo ago