I set out to build the app that would save the world. Embedding YouTube turned out to be the easy 10%.

A developer built a Windows desktop app with Tauri and Rust that plays YouTube videos in a small always-on-top window, designed to hide quickly with a hotkey. The project was originally planned as a Chrome extension, but limitations in Chrome's extension API pushed it to a paid desktop app first. The developer found that distinguishing video buffering from YouTube blocking the video was the most time-consuming challenge.

I set out to build the app that would save the world. Reader, it does not save the world. What it actually does is sit in a small always-on-top window on your desktop, play a video or read an article out loud while you pretend to be deep in a spreadsheet, and vanish completely the second you hit a hotkey because your boss just walked past your desk. Grandiose delusions of world-saving aside, here's the part of that pitch that actually mattered: this was originally supposed to ship as a free Chrome extension first, with a paid desktop version following later only if anyone cared. That's not what happened. Chrome's extension commands API only lets you register a couple of fixed shortcuts, and the user has to go rebind them from a separate chrome://extensions/shortcuts settings page, not from inside your own UI — dead on arrival for something whose entire premise is "the hide-everything key has to feel instant and yours." And getting a real always-on-top, frameless, click-through floating window to behave consistently inside an extension's sandbox turned out to need a lot more rework than I'd budgeted for. So the free extension is still on the shelf getting redesigned, and the paid Windows desktop app — Tauri, Rust backend, real OS-level global hotkeys — ended up finished and shipped to the Microsoft Store first instead. Once that decision was made, I figured the actual video feature would be the fast part: grab YouTube's IFrame Player API, drop it in a frameless window, ship it before lunch. That's not remotely how it went either. The floating-window shell and hotkeys came together fast. What ate most of the development time had nothing to do with UI: reliably telling apart "the video is buffering" from "YouTube just silently blocked this and nothing is ever coming." Since it's a small floating window, I wanted the video to fill the whole frame edge-to-edge rather than sit inside black bars — closer to how a phone lets you pinch-zoom a video than how a normal embedded player behaves. An <iframe doesn't support object-fit: cover the way a real <video element does, so the actual video area has to be deliberately oversized and then shifted with plain positioning: function iframeW { return Math.round clip.clientWidth zoomPct / 100 ; } function applyCropPos { const w = iframeW ; const h = Math.round w 9 / 16 ; const extra = clip.clientHeight - h; const bottom = extra 0 ? Math.round extra / 2 : yOff; f.style.cssText = position:absolute; bottom:${bottom}px; left:calc 50% + ${xOff}px ; transform:translateX -50% ; + width:${w}px; height:${h}px; border:none; ; } The iframe is always forced to a true 16:9 box computed from the window's width, not the video's — then whatever doesn't fit vertically just hangs off the top/bottom of the visible clip area, and dragging or scrolling only ever nudges xOff / yOff , which get clamped so you can't drag the video away from the window entirely: js function clampCrop { const w = iframeW ; const h = Math.round w 9 / 16 ; const minY = - Math.max 0, h - clip.clientHeight ; yOff = Math.max minY, Math.min 0, yOff ; // never scroll past either edge const exX = Math.max 0, w - clip.clientWidth / 2 + 80; // small overshoot allowance either side xOff = Math.max -exX, Math.min exX, xOff ; } This part behaved exactly like I expected going in: fiddly math, but nothing surprising. Here's the failure mode that took the longest to nail down. Every so often, autoplay just... doesn't. The player loads, the frame renders, and nothing plays — no error, no exception, no event fires to tell my code anything went wrong. From the outside, a genuinely stuck video and a video that's still buffering on a slow connection look identical: a static frame sitting there doing nothing. What's actually happening, most of the time, is that YouTube served an interstitial instead of the video — a "confirm you're not a bot" style challenge, sometimes triggered by embedding from an unfamiliar app context. There's no JS callback for "the embed you requested got swapped for a captcha screen." So the app has three independent ways of guessing at it, from most to least trustworthy: Mechanism 1 Rust side, primary : read the actual API response. YouTube's embedded player talks to an internal endpoint /youtubei/v1/player that returns a playabilityStatus field, and the Rust backend intercepts that network response directly through the WebView2 APIs to inspect it — the same kind of interpretation logic the open-source yt-dlp project uses to distinguish a genuine bot-check/CAPTCHA state from things that look similar but aren't, like an age-restriction notice which needs a completely different response — that one isn't "stuck," it's working as intended, just gated : php fn is bot check reason playability: &Value - bool { let reason = playability.get "reason" .and then Value::as str .unwrap or "" .to lowercase ; let status = playability.get "status" .and then Value::as str .unwrap or "" .to lowercase ; let is age gate = playability.get "desktopLegacyAgeGateReason" .is some || AGE GATE REASONS.iter .any |k| reason.contains k || status.contains k ; if is age gate { return false; } // age-gated is a different problem, not "stuck" let has captcha signal = playability.pointer "/errorScreen/playerCaptchaViewModel" .is some ; has captcha signal || reason.contains "this helps protect our community" } Mechanism 2 fallback : ask the WebView what text is actually on screen. Using the Chrome DevTools Protocol DOM.getDocument with pierce: true to see through the cross-origin iframe , the Rust side pulls the rendered text every couple of seconds and checks it against a short list of phrases. This one only exists because mechanism 1, however solid it feels, is still inference from an internal API response format that isn't a public contract — if YouTube reshapes that response, this is the safety net. Mechanism 3 last resort, in the JS layer : a plain timeout. If neither of the above caught anything and 12 seconds have passed since autoplay was supposed to start with still no PLAYING state, assume it's stuck anyway: js function armStuckTimer { stuckTimer = setTimeout = { if everPlayed showBlockOverlay ; }, STUCK TIMEOUT MS ; let pollsLeft = Math.ceil STUCK TIMEOUT MS / DOM POLL INTERVAL MS ; domPollTimer = setInterval async = { if everPlayed || --pollsLeft <= 0 { clearInterval domPollTimer ; return; } const found = await invoke "check bot check dom" ; if found && everPlayed showBlockOverlay ; }, DOM POLL INTERVAL MS ; } That pollsLeft countdown matters more than it looks: mechanism 2 is a DevTools Protocol round-trip into the WebView asking it to walk its entire DOM tree, which isn't free to run forever. It only polls for the same window that the plain timeout is already counting down — once the video actually starts playing, or the timeout budget runs out, the interval clears itself instead of quietly polling for the rest of the video's runtime. When any mechanism fires, the app shows an overlay with two honest options: reload the player, or sign in with your Google account first some of these walls go away once the embed is running with a logged-in session and then reload. It's not a magic fix — it's just not leaving you staring at a silently frozen black rectangle with no idea what happened or what to try next. Crop mode looks great for casual watching, but it hides YouTube's real control bar, so there's a toggle to temporarily switch to the official player chrome when someone needs subtitles, quality settings, or the actual seek bar: async function toggleNativeMode { savedSize = { w: window.innerWidth, h: window.innerHeight }; const videoW = Math.max window.innerWidth, NATIVE MODE MIN WIDTH ; const videoH = Math.round videoW 9 / 16 ; clip.style.cssText = position:absolute; top:${TOP STRIP HEIGHT}px; left:0; width:${videoW}px; height:${videoH}px; ; await win.setSize new LogicalSize videoW, TOP STRIP HEIGHT + videoH + BOTTOM STRIP HEIGHT ; } The mildly interesting part is how the layout avoids fighting itself: the window resizes taller, the video area gets pushed down below a fixed-height strip at the top and above one at the bottom, and the drag handle / close button / gear icon — which were already pinned to the window's edges by CSS, not positioned relative to the video — just naturally land in that newly opened space without needing to be recalculated at all. Toggle it off again and savedSize restores the exact width/height it had before, so flipping back and forth doesn't slowly drift the window to a different size each time. None of the three detection mechanisms are bulletproof, and I don't pretend they are: There's also a read-aloud mode in the same floating-window shell — paste in an article or a novel excerpt and it reads it back to you sentence by sentence, which turned out to have its own gremlin the browser's speech engine can silently stop mid-sentence with no error at all , but that's a story for another post. The video mode was where the real fight was. I ended up shipping the whole thing as Yarn Thread - Pro https://apps.microsoft.com/detail/9nc2tb65qcsf — the always-on-top window described above, hotkey and all. It hasn't saved the world yet. It has gotten me through a lot of boring afternoons.