As reported by Ralph Alvy and several others on the forums (https://forum.xojo.com/51170-2018r3-web-app-appears-stuck-when-it-quits/0#p414878) and in Feedback (53291) Xojo web applications built in Xojo 2018r1+ can lock up with no visual indication or recovery.
In Xojo 2017 and before this was not a problem because the entire communication stack between the browser and server was built on XMLHttpRequest. This is the browser provided class that enables all AJAX interactivity on the web. Since the inception of AJAX however many new technologies like WebSocket’s and Server-sent Events (SSE) have been released.
They provide a persistent connection between the browser and server in either bidirectional or unidirectional capacities. This helps web applications respond faster to changes as building up a request is very expensive in regards to latency and when generating tons of events can really impair web application performance.
In Xojo 2018r1+ the web framework now defaults to SSE as opposed to XMLHttpRequest for all devices (except Firefox). This is great but unfortunately there is a bug. When a users session times out the users browser needs to be reloaded so a new session can be created and use continued. In the old XMLHttpRequest handlers this was recognized and if a session is no longer available on the server then the browser reloads itself.
Sadly, with Xojo’s SSE implementation there is no recognition that the connection to the server has been closed. A generic error has fired but because Xojo Web was working fine prior to the users tab being suspended it is not aware of connectivity issues. The app essentially locks up from the users perspective as the web framework is no longer listening for server side events and client generated events are no longer capable of firing as the session is invalid. Technically the client generated events do fire but the server rejects them.
Fortunately, there is an easy fix! When the SSE connection is closed the ‘readyState’ property of EventSource (https://developer.mozilla.org/en-US/docs/Web/API/EventSource) changes to the integer 2. I have verified a fix for this behavior by dynamically changing the error handler of Xojo’s SSE implementation to recognize a ‘readyState’ of 2. When it sees that it recognizes there is no recovery possible and it then starts pinging the server to see if it is still available. If it is then it reloads the browser and starts a new session exactly as the XMLHttpRequest implementation does.
Add an event handler for the ‘Shown’ event for the first WebPage in your Xojo Web project if it does not already exist.
Add the following code:
That’s it! You can now deploy your app and verify the fix works on ALL devices.
Feedback for Xojo
There is a lot of parsing in the framework going on for WebSockets, Server-sent events, and conventional AJAX to identify when connections have broken, server unavailable, etc. In most cases you capture these events just fine and do the appropriate thing. However, at times when you miss one the web applications appears “locked up” with no obvious way to resume. You don’t know if it is lagging out, frozen, or what.
I recommend when the server sees data being sent to a session that is no longer valid that instead of returning a generic 404 you send back a “session invalid error” that can be handled. You can then force the browser to reload regardless of the failures that led to the error in the first place. If the session is invalid there is no point in letting the client linger any longer than necessary as no recovery is possible.
There is a lot of EventSource handling code in Xojo.comm.ajax that relies on message counting to determine if there was connectivity failure. However, if connections break down or fail there is no graceful cutover back to XMLHttpRequest as a fail safe. The current implementation just reloads the browser and then attempts to use SSE again despite a failure in the previous attempt. Instead gracefully switch to XMLHttpRequest and only then if failures persist continue with a reload.
You should revisit the absence of using SSE in Firefox. Mozilla is very standards based and I’m sure appropriate workarounds could be implemented to support this methodology.
One of the great things about Xojo Web is I can investigate and fix the client-side issues. I hope this provides some evidence that an open source standard library would be a good thing! The bits that make Xojo the most valuable (The IDE, the compiler, etc.) can and should remain closed source. The non-proprietary implementations of standard protocols (SSE) could benefit from more eyes on them in my opinion. See part 2 of my 2017 review series on where I talked about opening up more of Xojo’s standard libraries for cases just like these: http://www.dev.1701software.com/blog/xojo-in-2017-part2