Unfortunately, you’re running into a pretty frustrating part of a lot of unfriendly systems (not) working together. It’s really shitty this should come up in the middle of a client demonstration.
Generally, there’s nothing in the
meteor code (or indeed any typical websocket client or server code) that causes inappropriate, unrecoverable or unresponsive connections.
Chrome 57 and later has pretty aggressive backgrounding. Even if their own documentation (https://developers.google.com/web/updates/2017/03/background_tabs) says that they give exceptions of some kinds of processing to websocket applications, who really knows what their policy is at any given moment (I certainly couldn’t get a straight answer from the source code, which is what I usually do to help folks out).
Safari too has powersaving features that may be surprising.
I don’t know how modern Firefox would respond. Firefox 58 ESR notifies you when it does surprising things. So if there was a problem with the browser disconnecting a long-running tab’s connections in an unrecoverable way, it will tell you.
There was an issue about this from a while ago that I could not find. The recommendation for kiosks was to use Firefox’s kiosk mode. That’s what I’d suggest in your case.
As an aside, I’m not a full-time front-end web developer, so my familiarity with these sorts of issues is limited. But one of the things you can be pretty confident of is that Google Chrome isn’t as great as it appears; Google Chrome on Windows (which I suspect may be another aspect of your equation) or Android is even worse. If you can run Firefox 58 ESR in kiosk mode inside an Ubuntu LTS machine (or if you’re really crazy, a modern OpenBSD), you’ll experience the smoothest and most consistent behavior.