search

HeinrichApfelmus / threepenny-gui

GUI framework that uses the web browser as a display.
https://heinrichapfelmus.github.io/threepenny-gui/
Other
437 stars 77 forks source link

Web socket refresh fix #135

Closed blitzcode closed 7 years ago

blitzcode commented 8 years ago

Looking into this some more, simply refreshing the page on disconnect seems to be a sensible solution. I played around with FF, Chrome, OS X & iOS Safari, and that pretty much fixes #130. I'm not sure there's a better solution given the architecture of threepenny applications, at least I'd be very happy with having this simple fix merged, it improves the current situation of constant stale/dead pages considerably.

HeinrichApfelmus commented 8 years ago

Thanks for addressing this with a pull request!

I'm not entirely sold on this solution, though. It certainly works for applications which transmit all relevant state at each reload. However, in some cases, it may be desirable to keep the current page dead (to be able to copy & paste whatever is there) before establishing a new connection to the server. I think the solution should be part of the startGUI configuration.

Of course, a log entry with Haskell.log would be appropriate in either case.

blitzcode commented 8 years ago

Hm, I don't really know enough about threepenny internals to add a configuration variable for this behavior! I still think it would be a good idea to merge this rather simple fix.

Right now, a threepenny application freezes every time a tablet goes to sleep, a laptop lid is closed or a tab is switched on a mobile phone. This problem has a noticeable impact on usability, and there seems to be no reliable way to work around this problem from outside the library. In most cases the thing the user is going to do anyway is hit the reload button after a few frustrated clicks on the page. I also could imagine that there's an application that keeps some state client side, like a text box that has yet to be submitted. But unlike the disconnect issue, that could be worked around, i.e. by submitting the content to the server and is also very much in line with how many browsers work. Having a tab evicted from memory generally reloads the page and clears client-side state, it's something that users are likely aware of. GitHub wouldn't save this post if I refreshed the page or the brower would be evicted from memory on a mobile device.

I also don't think there's a better general solution for this problem, as you'd have to buffer all messages server-side for the client, hoping it'll return soon. This could be get out of hand quickly, like having a machine wake up from sleep and getting the last few hours of messages for a stock ticker app delivered.

HeinrichApfelmus commented 7 years ago

Thanks for suggesting a fix! I have implemented this with an option in commit 5ccc078e1b2731e49b9d0bbba153589e07ecdd30 . More discussion in issue #130 .