August 2019: Chrome users suddenly getting disconnected from old WE app

Two stand-alone Web Edition apps running on the same WIndows 2012R2 server.

Older web app was written about 5 years ago with almost no changes since then. The newer one was written about three years ago. Windows updates are applied monthly.

Latest monthly windows updates were applied a few days ago.

Today, users of the OLDER app connecting via Chrome started having a problem:

  1. User connects to older app with Chrome.
  2. App works fine for 20-60 seconds, allowing user to switch pages, etc.
  3. User is disconnected from server and immediately gets the “Launching…” screen as Chrome reconnects to the server and reloads the start page…
  4. Chrome reconnects and app works fine for another 20-60 seconds before disconnecting/reconnecting again.

NO problems if the user uses Firefox.
NO problems if the users connects to the other, newer Xojo web app running on the same server.

Given that everything has worked fine for years, I’m guessing that either something has gotten corrupted, or there’s some bad interaction between the older Xojo web app with the latest Windows and Chrome updates (a 3-way conflict).

Anyone see anything similar? Any thoughts?

Just to clarify more, Firefox users can work without any problems at the exact same time that Chrome users are getting disconnected. The stand-alone server app on the server does not crash or report any problems even while the Chrome users are getting bounced.

Are the “old” and new apps compiled with diferent version of xojo? If not, can you recompile in the more recent one?

Also worth noting: ALL Chrome sessions get disconnected simultaneously–multiple users on multiple systems while the people connected with Firefox don’t see any issue at all.

I’ve restarted the server and recompiled the web app using 2019r1.1 and sessions now last as long as 20-30 minutes. I haven’t identified any pattern yet, but find it very interesting that ALL of the Chrome clients disconnect simultaneously when it happens.

You mean they disconnect at the same time even if they start at very different times from each other?

Yes–exactly. ALL clients connected using Chrome browsers get disconnected at the exact same moment. That includes users on different computers AND multiple Chrome sessions running on one computer. Doesn’t matter when they all connected, they ALL disconnect at the same instant, followed by Chrome immediately reconnecting to the default page (with a momentary flash of the launching icon).
Meanwhile, Firefox sessions stay connected just fine through the whole thing, even if a Chrome session goes through the disconnect moment on the same computer.
Again, this app was working for years, so it’s got to be something that got corrupted or else a recent change to Chrome and/or Windows Server 2012R2.
We’ve tried rolling back the Windows Server 2012R2 updates and that didn’t help either. Seems like a Chrome thing. It even impacts Chrome running on a phone.
Weird.

Do you have any code in Session.TimedOut?
Do you have any code anywhere with Session.Quit?
In the Session object, do you have any code with Quit or Self.Quit?

No session.TimedOut event handler at all. No “quit” anywhere in the session object. No session.quit code getting triggered anyplace else. From what I can see, I don’t think the session.close event is getting triggered, although i’m not 100% certain of that.

I would make sure you have Password Autofill turned off in Chrome. We have had found major performance issues with it . They go away if you disable the Autofill.

None of my test machines have names or passwords saved, but they run into the same issue as everyone else.

chrome seems to drop connections (websocket) if there has been no activity for around 60 seconds.
So if Xojo is connected trough websockets, and doesn’t send a “ping” or other information within these timeout a chrome client can be disconnected. But that doesn’t explain why they are all disconnected (if they are not the same browser/computer) at the same time.

[quote=451738:@Derk Jochems]chrome seems to drop connections (websocket) if there has been no activity for around 60 seconds.
So if Xojo is connected trough websockets, and doesn’t send a “ping” or other information within these timeout a chrome client can be disconnected.[/quote]
Xojo Web does not use WebSockets.

Yes i know, eventsource is what xojo uses right?
Anyway these are the reports i noticed, and may as well happen to other keep-alive sockets

[quote=451760:@Derk Jochems]Yes i know, eventsource is what xojo uses right?
Anyway these are the reports i noticed, and may as well happen to other keep-alive sockets[/quote]
If that’s the case then something’s seriously broken in chrome.

Has nothing to do with whether there are any passwords stored. It has to do with Chrome processing every input field on your page to determine if its something that should be autofilled. From our experience WE works much better with any browser when it has the autofill turned off.

Have you tested this on the server locally or via a machine that is patched directly to the server to eliminate a hardware issue?
Have you tested this app on a different web server or running in debug mode via the ide?
Have you wire sharked the comms?

Unfortunately, company policy prohibits Chrome from being installed on the servers. The Chrome drops occur for users both internal and external (with internal users separated from the server by a single switch and just a few feet).
I’ll be doing more testing this week–we’ve gotten most people to switch to Firefox in the interim. The app is scheduled to be removed from usage in a couple of months, so we might just limp along with it, telling people to use Firefox for the remaining time, but it’s a very disconcerting issue…