LiveServer.jl icon indicating copy to clipboard operation
LiveServer.jl copied to clipboard

Client-side loop to re-establish broken WS connection

Open tlienart opened this issue 5 years ago • 6 comments

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 avatar Apr 05 '19 00:04 tlienart

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.

asprionj avatar Apr 05 '19 21:04 asprionj

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 :shrug:

tlienart avatar Apr 06 '19 07:04 tlienart

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?

asprionj avatar Apr 06 '19 13:04 asprionj

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?

tlienart avatar Apr 06 '19 23:04 tlienart

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

asprionj avatar Apr 07 '19 10:04 asprionj

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

fonsp avatar Mar 25 '22 20:03 fonsp