-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client-side loop to re-establish broken WS connection #23
Comments
That is almost impossible to solve. The problem is that, as soon as you click the link, the browser navigates to this link, i.e. it navigates away from the page containing the link. Whenever leaving a page, open websocket connections are closed by the browser (which makes perfect sense). This is not reverted once the browser notices that the correct action for this link is to actually download a file. You can test this; if you right-click the link and download the file directly, the websocket connection is preserved. One solution to that is to set the target of the link to a new window/tab using <a href="/files/zip-file.zip" target="_blank">Download a ZIP file</a> Like this, the link is opened in a new browser tab, which is directly closed again since the browser notices that it is a file to be downloaded, not to show. |
Yeah I think if this is well documented it doesn't really matter. The use-case would be kind of rare anyway and to test that the link works but if the user knows they have to just reload 🤷 |
Another option would be to include in the client-side JS code a loop that regularly checks the state of the websocket connection and automatically reconnects if it closed. Like this, navigating away to follow a download link would not break the updating. This could also help with other causes of broken websocket connections (no concrete examples, but I'm sure there's other stuff that can kill them). Do we want this in for the Initial Announcement? |
Probably not, I think it's a bit of a weird use case, let's fix the simple stuff first and then possibly we may have people using it suggesting ways of doing stuff. The idea of the loop on JS side is potentially a good one though we'd have to make sure it's also stopped properly. Maybe something for the future. Let's keep this issue open for now and revisit later? |
Yep, something for the future. Renamed the issue to indicate what the intended improvement is. We'd not have to explicitly stop the loop; it would automatically cease once the page is closed (by definitely navigating to another page, an update triggered from the server, closing the tab/browser, ...). |
We have some well-tested WS reconnection code here, this might give some inspiration :) https://github.com/fonsp/Pluto.jl/blob/v0.18.4/frontend/common/PlutoConnection.js |
This is not entirely reproducible but try:
It's unclear to me why but it should be sorted out.
Edit: just add this to the docs with explanation provided by Jonas
The text was updated successfully, but these errors were encountered: