Screen Recorder

What screen capture can and cannot see

The browser mediates the entire process. A page asks to capture something, and the browser — not the page — presents the picker, decides what may be offered, and shows a persistent indicator while capture is running. The page never learns what is available until the user has chosen, and cannot pre-select a particular window or start capture without an explicit interaction. This design exists because screen contents are among the most sensitive things a device holds, and it is why the permission cannot be remembered the way a camera permission can: every recording requires a fresh, deliberate choice.

Why the file is so large

Screen content compresses differently from camera footage. Video codecs are built around the assumption that most of the frame changes slightly between frames, which is true of a moving scene and false of a mostly static screen punctuated by sudden scrolls. The result is efficient encoding for long still passages and large spikes whenever the whole frame changes at once — scrolling a page is close to the worst case, since every pixel moves but the content is unchanged. Capturing a smaller region helps more than any quality setting, because the cost scales with pixel count.

Ending a capture in all the ways it can end

A recording can stop for several reasons, and only one of them is the page’s own button. The user may press the browser’s stop-sharing control; they may close the window being captured; they may disconnect a display. In each case the browser ends the video track without notifying the recorder, and code that only listens to its own button simply stops receiving data with no indication that anything finished — the take is never assembled and the recording is silently lost. Handling it means listening for the track ending as well, and treating that as a stop. The same applies to the page being navigated away from, where the capture must be released rather than left running against a tab that no longer exists.