Coding With David

When we need a new UI feature in Blazor, our default reflex is often to hunt down a NuGet package, a third-party component library, or write an elaborate C# wrapper. But modern browsers already handle many of these capabilities natively—often much better than a custom abstraction would. Picture-in-Picture (PiP) is a classic example. Whether you are floating a video feed or creating an always-on-top dashboard monitor, the browser provides direct APIs to manage these detached windows. However, wiring PiP into a Blazor Server application reveals a subtle architectural trap: browser user-activation requirements . Here is how the Picture-in-Picture APIs work, why standard Blazor @onclick handlers break them, and how to structure JavaScript interop so the browser and server cooperate cleanly. The Blazor Server SignalR Trap Most browser features that affect windowing or OS integration require transient user activation . The browser will only execute methods like video.requestPictureInPictur...

You add some JavaScript to a Blazor page, test it locally, and everything runs as expected. Then you navigate to another route, click back, and nothing happens. Press F5 to refresh, and it works again. When this happens, it’s easy to blame timing issues, Blazor lifecycle quirks, bad CSS selectors, or browser caching. But more often than not, your JavaScript isn't broken—your assumptions about the browser's document lifecycle are. The real problem? The browser never actually loaded a new page. Modern Blazor Web Apps use enhanced navigation , which fetches new HTML in the background and patches the DOM without executing a full document reload. It makes navigation feel instantaneous, but it completely upends a mental model developers have relied on for decades: navigating to a page doesn't mean the browser re-executes that page's scripts. Let's break down why this breaks traditional JavaScript, how to reproduce it, and how to fix it cleanly using native Blazor capabil...