Fix reconnect on visibilitychange never running (window.hiddenProperty is always truthy)

[TowyTowy]

What & why

Fixes #498.

ServerConnection._onVisibilityChange() never reconnects the signaling socket when the page returns to the foreground:

_onVisibilityChange() {
    if (window.hiddenProperty) return;
    this._connect();
}

window.hiddenProperty (set in util.js) is the name of the visibility property — the string 'hidden' (or a vendor-prefixed variant), not the page's visibility state. A non-empty string is always truthy, so the guard always returns early and this._connect() is dead code: the client never re-establishes the WebSocket on visibilitychange.

git log -L shows this was introduced in 2a837eb ("add 'visbilitychange' event support for older browsers"), which changed if (document.hidden) return; to if (window.hiddenProperty) return; and dropped the document[...] indexing.

Fix

Index document with the property name, restoring the original pre-polyfill behaviour while keeping vendor-prefix support:

if (document[window.hiddenProperty]) return;

The guard now returns early only while the page is actually hidden and lets _connect() run when it becomes visible — the intended recover-on-return path. This most visibly affects standalone PWAs (e.g. iPadOS home-screen web apps) whose socket is severed while backgrounded, which is the symptom reported in #498.

Verification

• node --check public/scripts/network.js passes.
• Standalone Node harness replicating the util.js polyfill + both guards: hidden page → _connect() correctly skipped (before and after); visible page → skipped before the fix (the bug), called after (correct); vendor-prefixed (webkitHidden) visible page → correctly calls _connect() after the fix.
• The hiddenProperty === null path (no visibility API) is unaffected: visibilityChangeEvent is then also null, so the listener never fires.

Out of scope (possible follow-up)

Issue #498 also notes that on iPadOS the resumed socket can be a "zombie" whose readyState still reads OPEN, so _connect()'s _isConnected() early-return may skip reconnecting even after this fix, since the client has no self-initiated ping timeout. Robustly handling that changes cross-platform behaviour and can't be verified without the physical device, so I've left it out of this minimal, deterministic fix.

---

Disclosure: this one-line fix was prepared with AI assistance (Claude); the root cause, the change, and the verification above were reviewed before submission.