fix: use wss:// for WebSocket on HTTPS pages

[adnaan]

Summary

• Fixed WebSocket URL always using ws:// regardless of page protocol
• On HTTPS pages, browsers block mixed-content WebSocket connections with SecurityError
• Now detects window.location.protocol and uses wss: for HTTPS pages

Root Cause

transport/websocket.ts:206 always constructed:

return `ws://${window.location.host}${liveUrl}`;

Behind TLS-terminating reverse proxies (Fly.io, Cloudflare, AWS ALB), the page loads over HTTPS but the client tried to open a ws:// WebSocket — browsers reject this as mixed content.

Fix

const wsScheme = window.location.protocol === "https:" ? "wss:" : "ws:";
return `${wsScheme}//${window.location.host}${liveUrl}`;

Test plan

• All 213 client tests pass
• Verified with chromedp E2E test against Fly.io deployment (HTTPS → wss:// → WebSocket connected)

🤖 Generated with Claude Code

[claude]

Review:

The fix is correct and necessary. Hardcoding ws:// would cause mixed-content errors and connection failures when the page is served over HTTPS — browsers block insecure WebSocket connections from secure pages.

The scheme detection logic (protocol === "https:" ? "wss:" : "ws:") is the standard approach and handles both cases properly.

No issues. LGTM.

[Copilot]

Pull request overview

Fixes WebSocket connections failing on HTTPS pages due to mixed-content blocking by dynamically selecting wss: or ws: based on the page protocol.

Changes:

• Replace hardcoded ws:// scheme with protocol-aware scheme selection for WebSocket URLs

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.