2021 R3.1 - Lost Connection Behavior Different?

Yup, I’ve noticed that also. It started happening after the entire https://forum.xojo.com/t/2021r3-how-do-i-debug-whats-triggering-websession-interruptionmessage/66925 debacle. But it’s not a game-breaker for me :slight_smile:

Doesn’t matter where it’s running. Just stop it (if in debugger) and you won’t see the disconnected message. At least that’s how I’ve noticed it.

@AlbertoD since you have the screenshots, would you be willing to submit a Feedback case (if there isn’t already one?)

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

Looking in the Safari console/debugger, it appears the browser realizes it has lost connection, as there are error messages each second:

but these never seem to trigger the “lost connection” message. Curious!

1 Like

Yes! That’s it!! :slight_smile: 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.

1 Like

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 having the same issue. Only in 2021 r3.1, the previous version was fine

I think it refers to my feedback but I’m not sure.
<https://xojo.com/issue/67089>

I submitted a new case to be sure:
<https://xojo.com/issue/67502>

2 Likes

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)

1 Like

Here is a super ugly hack which seems to fix the bug.

Run this code in the session.Opening() event:

Session.Opening

dim js() as string = Array( _
"console.warn('###  JSStartAjaxConnection Hack Installed ###');",_
"/* window.alert('###  JSStartAjaxConnection Hack Installed ###'); */ ",_
"var comm = session.comm; ",_
"comm.Hack = ",_
"  function() {",_
"    console.warn('### Replacing eventSourceSocket.onerror function ###');",_
"    eventSourceSocket.onerror = function(e) {",_
"      console.warn('### eventsourceMessageCount = ' + eventsourceMessageCount ); ",_
"      --eventsourceMessageCount < 1 && preventInteraction()",_
"    }",_
"  }",_
"comm.Hack(); /* install the hack */ "_
)

dim jstext as string = String.FromArray(js,EndOfLine.Windows)
self.ExecuteJavascript(jstext)

How this works:

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

7 Likes

This workaround seems to also have fixed the problem with “ghost” sessions sticking around.

I’ve been using it for severl hours now, and all sessions seem to be cleaning themselves up properly.

3 Likes

Now hope that Xojo will add this fix ASAP to Web so we can have a STABLE web for once.

1 Like

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.

Do reconnections even work?

1 Like

This Bug is at #60 at the moment.

Lets vote this on up!

https://xojo.com/issue/67502

1 Like

@Jay_Menna your link is bad - here’s the live link:

<https://xojo.com/issue/67502>

It’s now up to 26th position :sunglasses:

1 Like

Up to 15th now. :sunglasses:

Reported as “Fixed” but not yet released.