screen sharing for developers https://screego.net/
https://github.com/screego/server
740 forks.
10,751 stars.
18 open issues.
Recent commits:
- Add UI for setting stream resolution (#252), GitHub
- Merge pull request #254 from LandmineHQ/fix/room-id-url-encodingfix(ui): decode room id from URL and encode it when writing back, GitHub
- fix(ui): decode room id from URL and encode it when writing backThe room id was read from the query string with a hand-rolled parser thatnever decoded it, while the id was written back into the URL without anyencoding: getFromURL = (key, search) => search.slice(1).split('&') .find((param) => param.startsWith(`${key}=`))?.split('=')[1]; window.history.pushState({roomId: id}, '', id ? `?room=${id}` : '?');Browsers percent-encode non-ASCII characters when a URL is serialized, so aroom named "不辞" is shared as `?room=%E4%B8%8D%E8%BE%9E`, but the client thenjoins the literal `%E4%B8%8D%E8%BE%9E` room, which does not exist: -> {"type":"join","payload":{"id":"%E4%B8%8D%E8%BE%9E"}} <- close 1000 "room with id %E4%B8%8D%E8%BE%9E does not exist"The same asymmetry also broke ids containing `&`, `=`, `+`, `#` or `%`, andmade ids that already contain percent escapes gain another encoding level onevery write, producing broken (double encoded) share links.Use the platform URL API, which decodes on read and encodes on write exactlyonce: new URLSearchParams(search).get(key) ?? undefined const params = new URLSearchParams(); params.set('room', id); window.history.pushState({roomId: id}, '', `?${params.toString()}`);No server change is needed: the room id stays the raw, human-readable stringthat the ws `create`/`join` payload and the server-side room map already use,and existing share links keep working.Verified: URL round-trip for 不辞 / "my room" / "a+b" / "a&b=c" / "100%",protocol-level e2e against a live server (encoded id -> "does not exist",decoded id -> joins, cleanup on owner leave), `yarn build` (tsc + vite) and`prettier –check src/useRoomID.ts`., landmineHQ
- Merge pull request #250 from swindi-dev/fix/transient-disconnectedfix: don't close peer connection on transient 'disconnected' state, GitHub
- fix: don't close peer connection on transient 'disconnected' stateBoth connectionstatechange handlers treated 'disconnected' the same as'closed' and 'failed' and immediately called peer.close().Per the WebRTC spec, 'disconnected' only means that ICE connectivity checksare currently failing. The connection frequently recovers on its own — briefnetwork hiccups, Wi-Fi roaming between access points, or NAT rebinding alltrigger it. Calling close() makes that recovery impossible, because a closedRTCPeerConnection cannot be reopened.The result was that a short network glitch permanently killed the stream andthe viewer had to reload the page. Leaving 'disconnected' unhandled lets thebrowser's own ICE recovery do its job.Refs #53, Jannis Mattheis
Was this post helpful?
Let us know if you liked the post. That’s the only way we can improve.