Skip to content
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

Open
tlienart opened this issue Apr 5, 2019 · 6 comments
Open

Client-side loop to re-establish broken WS connection #23

tlienart opened this issue Apr 5, 2019 · 6 comments

Comments

@tlienart
Copy link
Collaborator

tlienart commented Apr 5, 2019

This is not entirely reproducible but try:

  • open
  • click on the download zip link
  • get back on the page
  • modify source --> might not trigger update

It's unclear to me why but it should be sorted out.

Edit: just add this to the docs with explanation provided by Jonas

@tlienart tlienart added bug Something isn't working investigate labels Apr 5, 2019
@tlienart tlienart added this to the Initial Annoucement milestone Apr 5, 2019
@asprionj
Copy link
Contributor

asprionj commented Apr 5, 2019

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 target="_blank". For example:

<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.
Another option would be to make all download "links" call a JavaScript function. But that's overkill, I think.

@tlienart
Copy link
Collaborator Author

tlienart commented Apr 6, 2019

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 🤷

@tlienart tlienart added docs and removed bug Something isn't working investigate labels Apr 6, 2019
@asprionj
Copy link
Contributor

asprionj commented Apr 6, 2019

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?

@tlienart
Copy link
Collaborator Author

tlienart commented Apr 6, 2019

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?

@asprionj asprionj changed the title Clicking on links seems to sometimes cause the live server to stop updating Client-side loop to re-establish broken WS connection Apr 7, 2019
@asprionj
Copy link
Contributor

asprionj commented Apr 7, 2019

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, ...).

@tlienart tlienart removed this from the Initial Annoucement milestone Apr 9, 2019
@fonsp
Copy link
Collaborator

fonsp commented Mar 25, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants