I’ve put my Web2 app built with 2021 R3.1 in production, and there’s something different about how lost connectons are handled. I’m not yet sure of the steps to recereate it, but I think it happens when your browser tab is no longer frontmost (or maybe when your computer sleeps?) The end result is that the web app looks normal, but nothing works.
In earlier versions, you would always get the “Lost Connection” message, but that seems more hit or miss in 3.1.
Xojo2021R3, when I stop debug I always get a problem connecting or lost connection message after a few seconds
Xojo2021R3.1, when I stop debug I don’t get the message even after several minutes
I think someone reported a disconnection between 4 and 5 seconds of no activity without any message and the page looks like is active but nothing works. Maybe there is a Feedback about that (don’t remember right now).
Edit: Eddies with Xojo2021R3.1 debug stopped (after 2 minutes)
Where’s the web app running? Xojo Could? Linux box? Locally-OS? What browser are you using? Have had user’s have issues using a few web apps in Mozilla.
I use Linux servers for all my web apps, & did have to recompile from r3 to 3.1, to get the disconnection issue fixed, that pervaded the previously release. So far no unresponsive apps. When your app goes unresponsive, how’s the CPU look? - I Haven’t had the issue with API2.0, but in 1.0, if my app was really CPU intensive, even just for a moment, sometimes we could get the WebApps to “disconnect” from the Xojo backend and freeze-up without showing any “app disconnected” issue.
**No WebApps issues so far with 3.1 on debian Linux in my case.
Hi Mike - lol so we started a new web application today - and are just about done with a majority of the code… (it’s a video streaming service) - and low-and-behold, after a video plays for a few minutes - the app is completely unresponsive - minus the video still playing
Yes! That’s it!! Seeing the same type of output all related to comm/serverevent URL. Oddly - we haven’t had any issues in other apps. The only difference between other apps and this one is that we’re loading images for TV/Streaming networks from external URL vs internal/local ones. The services need to be in control of the images on their end…so hosting locally is not an option. Are you loading any external resources in your projects by chance?
Nope, and like @Gabriel_L I can reproduce this with a “Hello World” web 2 app with a single button just by stopping the debugger, so I think it’s definitely a bug in Xojo 2021 3.1.
I found the relevant javascript and addedd my comments:
In 2021 R2.1:
// note: this triggers on XHR error
// eventsourceMessageCount starts at 5
// when it reaches 0, it calls preventInteraction() which pops up the lost connection dialog
eventSourceSocket.onerror = function(e) {
--eventsourceMessageCount < 1 && preventInteraction()
In 2021 R3.1:
// note: this triggers on XHR error
// eventsourceMessageCount starts at 5
// however, it seems that eventsourceMessageCount is never decemented.
// because eventSourceSocket.readyState does not equal EventSource.CLOSED perhaps?
eventSourceSocket.onerror = function(e) {
eventSourceSocket.readyState == EventSource.CLOSED &&
--eventsourceMessageCount < 1 && preventInteraction()
The documentation for EventSource EventSource - Web APIs | MDN is not super clear, but I could imagine that readyState is never CLOSED inside the onerror handler, which may be leading to this bug?
I’m also seeing what I think is a related issue - I have an administrator view which shows me statistics on Active and Termiated sessions. In the old version, terminated sessions cleaned themselves up after a minute or two.
In 2021 R3.1, they seem to stick around - in this screenshot, every session noted with (X) is one that has been terminated, but still exists:
These “ghost” sessions don’t seem to be causing a big issue, but I imagine they are leaking a little bit of memory (and my app has only been running for about 24 hours - longer term, this would concern me)
the session.comm object has an eventSourceSocket, which has an onerror handler which has a bug in it
because the session.comm.eventSourceSocket is a “let” variable, we can’t simply replace it from outside the object (e.g. session.comm.eventSourceSocket is not visible from outside the scope)
instead, we add a function to session.comm called Hack()
since Hack() is within the comm scope, it can see the session.comm.eventSourceSocket variable, and replace the onerror handler with the non-buggy one from Xojo 2021R2.1
Use at your own risk of course!
Here’s what I now see in the console when running this:
Seriously Xojo please do a blog article or update the documentation to explain all the options related to timeouts, reconnections etc - I’m now totally confused as would appear to be the case for many about how these timeouts actually work.