confusingstraw commented on issue #50: URL: https://github.com/apache/incubator-flagon-useralejs/issues/50#issuecomment-807044442
@poorejc @UncleGedd I will try to keep this sane. 1. I don't think Web Workers help us very much, as [the spec](https://www.w3.org/TR/workers/) says that their behavior after their associated documents have gone away is implementation defined. Moreover, they are not allowed to respond to any additional events, so I don't believe they'd actually be able to observe the fact the page had closed. I could be wrong on the second point. Overall, there may be something there, but I am not confident that is the case. 1. [Service Workers](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) might be an effective alternative, as they let us run code regardless of whether the page is open (and regardless of whether there is an internet connection). The (large) downside is that it requires user-approval to install such a worker. 1. Websockets are great, the main drawback there is that we need to keep one open. This is maybe not so bad, but we also need to make sure it stays connected during periods of poor connectivity. We'd actually still run into the same issue we have now, though, since we'd still need to send a message when the page closes. I do not see any great resources describing how well that works. We could, however, potentially sidestep that requirement altogether by instead letting the _server_ decide when the page was closed. By observing the client disconnecting from the server (and potentially not reconnecting for some time), we can assume they closed the page. This, however, introduces false positives if the client simply lost connection for a long period of time. Maybe not a bad thing, since we could replace "closed the page" with "disconnected". 1. Another option would be keeping long-polling request or similar mechanic alive, and having the server assume that when it disconnects that the client has left the page. This has a similar drawback as the above. 1. Lastly, I believe one of the articles I linked mentioned using `Image` objects as a form of data exfiltration. This could (maybe) be more reliable, but it would require the server to accept data in a different format (since it would arrive as part of the `src` URL). Hopefully this was all coherent. I think Websockets are maybe the best, but I am not confident they actually completely solve the problem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
