A browser screen-sharing demo is straightforward: ask for a capture source and send the video track to a peer. Real use begins after that demo. Desktop text is tiny on a phone, so the viewer turns it sideways. They need to zoom into a line of code and pan with two fingers. The viewer refreshes, while the sender remains stuck on “sharing.” A recovered connection displays an old frozen frame without an end state.
A good session preserves the sender’s control, gives the viewer useful controls, and keeps state consistent on both sides. Resolution is only one part of it.
Select the smallest useful source
The browser picker commonly offers a tab, a window, or a display. For a single web demonstration, a tab reveals less and may receive better browser optimization. A window or full display is appropriate when the presenter must move among applications. Before sharing a display, hide notification previews, password-manager windows, and unrelated private material.
A website cannot remember a capture choice and silently reacquire it after refresh. Every new capture requires a user action. A trusted peer connection may recover automatically, but “the devices are online again” must not become “the sender is capturing again.”
Keep sender control persistent
While capture is active, retain a visible bar with source type, viewer count, duration, and Stop. The browser has its own capture indicator, but the product should not make a person hunt for a small browser icon. The stop action remains reachable after navigation or collapsing a sidebar.
If the browser toolbar stops capture, the media track fires ended, permission is revoked, or the source window closes, broadcast the termination reason and clear state immediately. Do not wait for a later viewer heartbeat, and never leave “sharing” in persisted UI until another refresh.
A viewer needs more than a video element
Desktop controls should include fullscreen, fit, native aspect ratio, audio or mute, quality state, and leave. Mobile adds landscape layout, pinch zoom, and pan. Zoom around the gesture midpoint, clamp minimum and maximum scale, and constrain pan so the entire image cannot disappear. Double-tap can toggle fit and a useful zoom level.
The gesture layer must not cover Leave or Fullscreen, nor should the page scroll while panning the shared image. Landscape is a viewing layout, not permission to force the operating system’s orientation. If Screen Orientation support is available, request it after the user enters fullscreen; otherwise show a small rotation hint.
What happens when the viewer refreshes?
When B refreshes, the old viewing session and media receiver are gone. After a short grace period, A should receive viewer departure or session closure and decrement the count. If no viewers remain, the sharing task can become “waiting for a viewer” and offer Continue or Stop instead of claiming an active audience forever.
After B reconnects as a trusted device, the page may show that A has an available share and let B rejoin deliberately. Signaling and WebRTC can recover automatically, but the site should not play a remote screen in the background before B returns to the viewer. Every join has a new viewer session ID so messages from the former page cannot change current state.
Quality, congestion, and route changes
Screen content differs from a camera. Text and interface details benefit from resolution, while static documents do not need 60 frames per second. Prefer resolution with a lower frame rate for quiet content, then increase frame rate for motion. Under congestion, lower frame rate, resolution, or bitrate in steps and show a “network limited” state instead of allowing unexplained blur.
Screen sharing can perform well through TURN because the media stack has mature congestion control. That makes it a useful comparison for file debugging: healthy screen media and extremely slow file data on the same relay do not automatically implicate relay bandwidth. A Wi-Fi-to-cellular change may cause a short pause, but a recovery timeout must end in a clear interrupted state.
Privacy boundaries of capture
Do not collect screenshots or place window titles and screen content in analytics. Useful events are request, selected source type, successful start, end reason, viewer-count range, and quality-degradation count. Recording is a separate feature that needs explicit agreement and a persistent indicator for everyone.
If a shared tab includes system audio, show the audio state separately. A viewer cannot control the sender’s mouse or keyboard unless another explicit remote-control protocol is approved by both sides. Permission to watch must not quietly expand into permission to operate the computer.
Boundary tests worth running
Test tab, window, display, and picker cancellation. After start, stop from the app, stop from browser chrome, close the source, revoke permission, and refresh the sender. Join, leave, refresh, disconnect, and background the viewer. Refresh both peers. Move from direct to relay. On mobile, test portrait, landscape, pinch, pan limits, fullscreen, and Escape. With multiple viewers, remove one and then the last.
At each step inspect both interfaces, track release, notification count, and whether an old session can return. Completeness is not “B saw A’s screen.” It is every exit returning both devices to a consistent, understandable state.
Share in uCopy
After connecting devices, choose screen sharing in the workspace and select a source. The sender can stop at any time. The viewer can enter fullscreen and use fit, zoom, and landscape layouts on mobile. After a refresh or network switch, watch for the session to return to viewing or end explicitly.
Screen capture is a continuing permission, not a bonus included with device trust. A clear start and a complete stop are what make people comfortable sharing material that actually matters.