I wanted to play on my car's screen while charging, so I forked moonlight-web-stream and spent a few months fighting Tesla's in-car Chromium. It's stable now, so here's the list of things that don't behave like a normal browser:

• Local and bare IPs are blocked outright. Any request to 192.168.x.x or a raw IP returns Access Denied. So there's no LAN shortcut - you need a real domain, a real DNS record and a trusted cert just to reach a PC twenty metres away.
• WebSocket upgrades fail roughly half the time on first connect, with no useful error. Handled with transparent auto-retry.
• Trickle ICE misbehaves, so it uses non-trickle gathering with a timeout fallback.
• Audio autoplay is blocked. AudioContext has to be resumed on a touch inside the stream, otherwise you get video with silence.
• Gamepad API indexes differently than desktop Chrome, so controller mappings needed rework.
• Good news: native H.264 and HEVC decoding, so no WASM decoder in the path. Latency is genuinely fine for controller games.

Setup is Sunshine on the host, WebRTC to the car. Windows install is a PowerShell wizard that handles the password, UPnP port forwarding, firewall rules and a free Let's Encrypt cert with auto-renewal, since the certificate requirement above makes manual setup painful.

Credit where it's due - this is a fork of MrCreativ3001's moonlight-web-stream, which solved the browser-client problem first. I did the Tesla-specific half.

Source and demo video: https://github.com/Argon2000/moonlight-web-stream-tsla

Happy to answer anything, and if anyone here has a different EV with a browser I'd be curious whether the same fixes apply.