标签：#javascript

Watermarking a PDF — adding semi-transparent text over pages — sounds like something only desktop software handles. But with pdf-lib and a bit of canvas math, you can build a fully browser-based watermark tool. This post walks through the implementation details, including text rendering, rotation, and multi-page support. Why client-side? Traditional watermark tools upload your file, process it on a server, and send the result back. For documents that might be confidential or contain sensitive information, this introduces an unnecessary privacy risk. A browser-based approach: Processes everything locally Keeps files on the user's device Works offline after loading Avoids server-side bandwidth costs The stack Vue 3 + Composition API pdf-lib for PDF manipulation and watermarks PDF.js ( pdfjs-dist ) for preview rendering Vite for bundling Adding a text watermark pdf-lib provides a built-in PDFDocument.embedFont() method for custom fonts and page.drawText() for placing text. Here's how to add a rotated, semi-transparent watermark across all pages: < script setup lang= "ts" > import { ref } from ' vue ' import { PDFDocument , rgb , StandardFonts } from ' pdf-lib ' const file = ref < File | null > ( null ) const watermarkText = ref ( ' DRAFT ' ) const opacity = ref ( 0.3 ) const fontSize = ref ( 72 ) const rotationDeg = ref ( - 45 ) const applying = ref ( false ) async function handleFileUpload ( selected : File ) { file . value = selected } async function applyWatermark () { if ( ! file . value ) return applying . value = true try { const arrayBuffer = await file . value . arrayBuffer () const pdfDoc = await PDFDocument . load ( arrayBuffer ) // Embed the Helvetica font — required for correct rendering const helveticaFont = await pdfDoc . embedFont ( StandardFonts . HelveticaBold ) const pages = pdfDoc . getPages () pages . forEach (( page ) => { const { width , height } = page . getSize () page . drawText ( watermarkText . value , { x : ( width - helveticaFont . widthOfT

If you've been developing with React Native or Expo for a while, chances are you've had a project that suddenly refuses to build for what seems like no reason. Maybe you installed a new package. Maybe you upgraded Expo. Maybe you only changed a single dependency. You confidently run your Android build, expecting it to compile like always... Instead, Gradle greets you with something like this: Execution failed for task ':app:checkDebugDuplicateClasses'. Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.8.2.aar and lifecycle-viewmodel-ktx-2.6.1.aar Duplicate class com.google.android.gms.internal.measurement.zzab found in modules play-services-measurement-base-22.0.0.aar and play-services-measurement-impl-21.6.2.aar Duplicate class ... At first glance, the error looks straightforward: there are duplicate classes . Easy enough, right? Not exactly. In reality, this is one of those Android build errors that can send you down a rabbit hole of Gradle files, dependency trees and Stack Overflow threads, only to realize the real cause was something completely different. Let's break down what's actually happening and, more importantly, how to fix it. Why this error happens Every Android library included in your project contains compiled Java or Kotlin classes. When Gradle builds your application, it combines all of those libraries into a single APK or AAB. If two different dependencies contain the exact same class, Gradle doesn't know which version should be packaged. Instead of guessing, it stops the build with a Duplicate class error. The difficult part is that the dependency causing the conflict usually isn't the one shown in the error. Very often, it's another package pulling in an older or incompatible version behind the scenes. The most common causes After seeing this error many times, these are usually the culprits. 1. Two libraries depend on different versions of the same package This is by far the most common scenario. For example:

Hi, my name is Dan, I'm a frontend engineer and open-source maintainer. I've spent the last couple of years building Nano Kit — a lightweight, modular state management ecosystem for modern web apps: signals-based stores , a router , data fetching , i18n , and SSR support , all built on the same tiny reactive core. It recently hit 1.0 , and in this post I want to give you four honest reasons to try it. 1. It's fast At the heart of Nano Kit is a push-pull reactivity system based on the algorithm from alien-signals — one of the fastest signal implementations in the JavaScript ecosystem. I didn't use alien-signals directly, though. Nano Kit needed things it doesn't provide, so I built a dedicated fork called Agera : Signal lifecycles — you can listen to signal activation and deactivation, which powers Nano Kit's mountable stores (run setup logic on first listener, clean up on last). Real tree-shaking — Agera is designed so that only the code you use ends up in your bundle; alien-signals is not well tree-shakable. The result keeps almost all of alien-signals' raw speed. Here is how @nano_kit/store compares to other popular state management libraries in a reactivity benchmark : Library Latency avg (ns) Throughput avg (ops/s) alien-signals 294.00 ± 2.24% 3,559,763 @nano_kit/store 303.55 ± 0.75% 3,365,816 svelte/store 428.58 ± 0.61% 2,479,118 rxjs 454.74 ± 0.07% 2,250,397 nanostores 1,373.2 ± 5.96% 952,399 mobx 3,474.7 ± 1.86% 306,094 valtio 5,041.3 ± 11.46% 254,109 jotai 9,454.6 ± 16.45% 157,853 effector 24,885 ± 11.78% 62,744 @reatom/core 59,430 ± 15.61% 22,741 Benchmark was run on AMD Ryzen 5 PRO 3400G with Node.js v24.14.1 That's ~3.5× faster than nanostores and an order of magnitude faster than most atomic state managers — while shipping lifecycles and mountable stores on top. 2. It's small Nano Kit exists largely because of Nano Stores . I love its philosophy: atomic stores, mountable resources, logic moved out of components, and an obsessive focus on bundle size. Nan

A background worker sits quietly for weeks, chewing through a job queue without incident, and then one Tuesday afternoon it disappears mid-batch, taking forty in-flight jobs down with it. No stack trace pointing at the offending line, no alert until a customer notices their export never finished. Nine times out of ten, the culprit is one of the most under-discussed failure modes in server-side JavaScript: unhandled promise rejections. They are easy to introduce, easy to miss in code review, and in modern Node.js they no longer just print a warning — they can end your process outright. This post walks through what unhandled promise rejections actually are at the engine level, why they are far more dangerous in long-running Node.js services than in typical web requests, how Node's default behavior around them has shifted over the years, and the concrete patterns you can use to stop them from quietly killing your jobs. What an Unhandled Promise Rejection Actually Is At the JavaScript engine level, a promise is a state machine with three possible states: pending, fulfilled, or rejected. When an async operation fails — a network call times out, a database query throws, a JSON parse blows up — the promise representing that operation transitions to the rejected state and carries a reason, usually an Error object. That's all a rejection is: a value flowing down the promise's error channel instead of its success channel. The engine only considers a rejection "handled" if, by the time it does its bookkeeping (which happens on a microtask checkpoint, not synchronously), there is a .catch() handler, a second argument to .then() , or a surrounding try/catch around an await somewhere in that promise's chain. If none of those exist anywhere in the chain, the rejection is classified as unhandled. This is the precise, narrow definition of unhandled promise rejections: a promise that reaches the rejected state with zero handlers attached anywhere along its chain of consumers. It's wo

I'll guide you through Python fundamentals by comparing concepts with JavaScript. Let's start! 1. Hello World & Basic Syntax JavaScript console . log ( " Hello World " ); let x = 5 ; Python print ( " Hello World " ) x = 5 # No semicolon, no let/const Key Differences: No semicolons in Python Indentation matters (replaces curly braces) Comments use # instead of // 2. Variables & Data Types JavaScript let name = " Alice " ; // string let age = 30 ; // number let isStudent = true ; // boolean let scores = [ 95 , 87 , 91 ]; // array let person = { // object name : " Bob " , age : 25 }; let nothing = null ; let notDefined = undefined ; Python name = " Alice " # str age = 30 # int (or float for decimals) is_student = True # bool (capital T/F) scores = [ 95 , 87 , 91 ] # list (mutable) person = { # dict (dictionary) " name " : " Bob " , " age " : 25 } nothing = None # Python's null/undefined Key Differences: Python uses snake_case (not camelCase) True / False capitalized None instead of null / undefined Lists ≈ Arrays, Dicts ≈ Objects 3. Control Flow JavaScript // If-else if ( age >= 18 ) { console . log ( " Adult " ); } else if ( age >= 13 ) { console . log ( " Teen " ); } else { console . log ( " Child " ); } // For loop for ( let i = 0 ; i < 5 ; i ++ ) { console . log ( i ); } // While loop let count = 0 ; while ( count < 5 ) { console . log ( count ); count ++ ; } Python # If-else (indentation instead of braces) if age >= 18 : print ( " Adult " ) elif age >= 13 : # NOT else if print ( " Teen " ) else : print ( " Child " ) # For loop (more like for...of in JS) for i in range ( 5 ): # range(5) = [0, 1, 2, 3, 4] print ( i ) # Iterate over list (like for...of) for score in scores : print ( score ) # While loop count = 0 while count < 5 : print ( count ) count += 1 # No ++ operator in Python 4. Functions JavaScript // Function declaration function add ( a , b ) { return a + b ; } // Arrow function const multiply = ( a , b ) => a * b ; // Default parameters function greet ( n

Nowadays, web frameworks come with ✨ magic ✨. Some more than others, but all of them have some. The...

I run a large fleet of "preview it, then download it as PNG" web tools — name tags, certificate generators, price cards, badges — in five languages: Japanese, English, Spanish, French, Portuguese. Canvas 2D text rendering looks correct as long as you only test Japanese and English. It breaks when you run es/fr/pt through it. After stepping on these repeatedly, the failures collapse into four patterns. The premise: Latin languages run 1.4–2× longer than Japanese Design data first. The same label, measured across five locales: Example ja en es fr pt Tool name 22 chars 35 62 48 50 "Standard" button 4 8 10 20 12 Rule of thumb: fr/pt come out 1.4–1.7× longer than ja; es can balloon to nearly 3×. A font size and maxWidth tuned to fit Japanese will not fit the Latin locales. All four failure patterns grow from this. Pattern 1: hand-rolled wrapping via text.split(/\s+/) collapses on CJK The classic snippet — split on spaces, wrap word by word — does nothing for Japanese or Chinese, where words aren't space-delimited. An entire sentence becomes one unbreakable token and clips at the canvas edge. Test with real Japanese input and check that the final line renders to its last character. "Most of it showed up" is not a pass. Pattern 2: an ASCII-only tokenizer splits words at accented characters Fix pattern 1 with a character-class tokenizer like [A-Za-z0-9'\-_] and you've traded one regression for another: ç é ã ó ñ aren't in that class, so produção fragments into produ / ç / ão mid-word. An English test will never catch this. Generate actual PNGs with fr/es/pt samples and eyeball the area around accented characters. I never found another detection method — string-comparison tests can't see a rendering-level split. Pattern 3: the important word at the end vanishes into "…" Since fr/pt run 1.4–1.7× longer than the ja the layout was tuned for, text overflows its two lines and gets ellipsized. The cruel part: what disappears is the tail of the phrase — often the semantically criti

For quite a while now, I've had the feeling that AI agents are surrounded by this mystical aura....

It started with the dumbest problem in computing: I'm in bed, a movie is playing on my laptop across the room, and pausing it requires physically getting up . Every existing fix annoyed me in some way. Remote desktop apps are overkill and route through someone's cloud. Remote-control apps want accounts, subscriptions, or a native app install. I just wanted my phone to poke my laptop over my own Wi-Fi. So I built LapDeck : one Node.js process on the laptop, a PWA on the phone. Scan a QR code once and your phone becomes an app launcher, touchpad, keyboard, live screen viewer, and media/power remote. MIT licensed, plain JavaScript, no build step. This post is about the four problems that turned out to be more interesting than I expected. The architecture in one line Phone (PWA) ── WebSocket + MJPEG over Wi-Fi ──► Node.js agent (Windows) The agent serves the PWA, exposes a WebSocket for commands, and streams the screen as MJPEG. The protocol is deliberately dumb JSON envelopes — no protobuf, no RPC framework — so a native Android client or a CLI script can speak it in an afternoon. Windows-specific glue (volume, brightness, power, capture) is isolated in src/win/ , so a macOS/Linux port only has to reimplement that layer. Problem 1: mobile keyboards lie to you The obvious way to build a remote keyboard is to listen for keydown and forward key codes. On mobile, this collapses immediately: swipe typing, autocorrect, and IME composition don't emit per-key events. Android will happily tell you every key is keyCode 229 . The fix: stop listening to keys entirely. I keep a hidden input, and on every input event I diff the field's value against the last known state — compute the common prefix, then emit "delete N chars, type this string" to the laptop. Swipe-type a whole word and the laptop receives one clean text insertion. IME composition, autocorrect rewrites, emoji — all just become diffs. The lesson generalizes: on mobile web, treat the text field as the source of truth, n

TL;DR Spent today rebuilding two training diagrams — a layered reference architecture and a workflow swimlane — as single-file HTML instead of exported images. The trick: data in a plain JS array, layout in CSS Grid, connectors in an SVG overlay measured at runtime . Result: diagrams you can step through, click into, and hand over as one file that opens offline. Why not just export a PNG? Because a screenshot is stale by the next sprint, and nobody re-opens the drawing tool to fix it. Approach Editable by a dev Interactive Portable PNG from a drawing tool No (need the source file) No Yes Mermaid in a doc Yes No Needs a renderer Hand-built HTML Yes (it's a data array) Yes One file, opens anywhere The third option costs a few hours once. After that, updating a component is editing one object in an array. Separate the data from the drawing This is the whole design. Nothing about position, colour, or DOM lives in the content: const TIERS = [ { key : ' clients ' , label : ' Clients ' , sub : ' consumers · admins ' }, { key : ' edge ' , label : ' Edge ' , sub : ' TLS · load balancing ' }, // ... ]; const COMPONENTS = [ { id : ' app ' , tier : ' app ' , x : . 34 , label : ' Control Plane ' , tech : ' PHP-FPM ' , role : ' Governance UI and sync orchestration. ' , points : [{ type : ' info ' , text : ' Pushes approved config downstream ' }] }, // ... ]; const LINKS = [[ ' consumers ' , ' edge ' ], [ ' edge ' , ' gateway ' ], /* ... */ ]; tier picks the row. x is a fraction (0..1) across that row , not a pixel. So the layout survives any viewport without me hand-tuning coordinates. Layout: Grid for the boxes, SVG on top for the wires +--------------------------------------------------+ | lane label | [card 1] [card 2] [card 3] | <- CSS Grid row |------------+-------------------------------------| | lane label | [card 4] [card 5] | +--------------------------------------------------+ ^ ^ sticky column SVG overlay (position:absolute; inset:0) draws paths between measured centre

GitHub热门项目 | Real-time token, cost, and AI limits widget with multi-device sync for Claude Code, Codex, OpenCode, Hermes, OpenClaw, Cursor, Antigravity and more. | 为 AI Tools 打造的即时Token、成本与限额监控桌面组件，支持多设备同步 | Stars: 904 | 199 stars this week | 语言: JavaScript

GitHub热门项目 | 求是Skill——从经典唯物辩证法与实践哲学中提炼出一条总原则和九大方法论工具武装AI大脑。Qiushi-Skill: Build agents that investigate first, focus on the main contradiction, validate in practice, and keep pushing until the work is actually done. | Stars: 3,597 | 14 stars today | 语言: JavaScript

Most apps start their access control with something like this: function canEditReportsSummary ( role ) { return [ ' EDITOR ' , ' ADMIN ' ]. includes ( role ); } It works, right up until you have a dozen pages, each with a few sections, each needing independent read/write rules per role. Now you've got dozens of these little arrays scattered across the codebase, and adding a new role means hunting down every single one and hoping you didn't miss any. 0 There's a much simpler model that scales cleanly: a three-level permission tree — page → section → { r, w } - plus one generic function that walks it. No new library, no framework lock-in, just a data structure and ~5 lines of code. The shape of the data Instead of scattering role checks in code, define one permission tree per role . Three levels deep: Page — the top-level feature/route ( dashboard , reports , settings ) Section — a sub-area within that page ( overview , summary , billing ) Action — r (read) or w (write) { "dashboard" : { "overview" : { "r" : true , "w" : false }, "analytics" : { "r" : true , "w" : false } }, "reports" : { "summary" : { "r" : true , "w" : false }, "export" : { "r" : false , "w" : false } }, "settings" : { "general" : { "r" : true , "w" : false }, "billing" : { "r" : false , "w" : false } } } This one blob fully describes what a single role can see and do. Give each role its own tree, e.g. for three common roles: Page Section Viewer Editor Admin dashboard overview r r, w r, w dashboard analytics r r r, w reports summary r r, w r, w reports export – r r, w settings general r r r, w settings billing – – r, w Notice how this reads almost like a spreadsheet a product owner could fill in — that's the point. It's declarative data, not scattered if statements, so non-engineers can review it and engineers don't have to guess what a role does. The generic access-check function Once permissions are just nested objects, checking access is one small, reusable, framework-agnostic function: function

I'm excited to share that I'll be speaking at React Day Berlin 2026 this December! My talk How I Brought React Into a Preact Form Engine: A Production Bridge Pattern I'll walk through how we integrated React into an existing Preact-based form engine in production — the bridge pattern we used, the trade-offs, and what I'd do differently next time. Duration: up to 20 minutes Dates: December 4 & 7, 2026 Format: remote or in-person (TBD) Join me (free stream access) You can register through my speaker badge and get partial free access to watch the stream: 👉 My React Day Berlin 2026 badge Speaker page: reactday.berlin/#person-sam-abaasi ReactDayBerlin #react #preact #javascript #webdev See you there!

🚀 JavaScript Fundamentals (Week-03): Understanding the Concepts That Every Developer Should Know "Writing JavaScript code is one thing, but understanding what happens behind the scenes is what makes you a better developer." When I first started learning JavaScript, I knew how to declare variables and write functions. However, I often found myself asking questions like: Why are there three ways to declare variables? What exactly is hoisting? How does JavaScript execute my code? Why can an inner function access variables from its parent function? What does the this keyword actually refer to? Why do developers keep talking about writing clean code? This week, I focused on understanding these core JavaScript concepts instead of simply memorizing syntax. In this article, I'll explain each concept in a beginner-friendly way with examples and practical explanations. 📚 Topics Covered Variables ( var , let , const ) Hoisting Lexical Scope Execution Context Call Stack Closures this Binding DRY Principle KISS Principle Let's start from the beginning. 📦 Variables in JavaScript What is a Variable? A variable is a named container used to store data in memory . Instead of writing the same value repeatedly, we store it inside a variable and reuse it whenever required. For example, let name = " Sai " ; console . log ( name ); Output Sai Here, let → Variable declaration keyword name → Variable name "Sai" → Stored value Why Do We Need Variables? Imagine writing this: console . log ( " Sai " ); console . log ( " Sai " ); console . log ( " Sai " ); If the value changes, every occurrence must be updated. Using variables, let name = " Sai " ; console . log ( name ); console . log ( name ); console . log ( name ); Now changing one line updates every usage. Variables improve: Readability Reusability Maintainability Types of Variables JavaScript provides three ways to declare variables. var let const Although all three create variables, they behave differently. var var was introduced in the

I built PunFiction: 1-Star Travel Reviews , a free daily web puzzle where you guess world landmarks by deciphering unhinged travel reviews from confused travelers. Tech Stack: Vanilla JS, CSS, HTML, GitHub Pages, MongoDB Atlas The Concept The internet can feel like it's literally overflowing with consumer complaints. I decided to take that negative energy and turn it into a 2-minute daily browser game for your morning coffee break. The Game Loop: Read an absurd 1-star review of a famous world landmark. Decipher the rhyming pun clues to guess the destination. Solving the puzzle unlocks an illustrated cartoon postcard and a sassy reply from the landmark 'manager'. The Tech Stack I wanted PunFiction to feel lightweight and lightning fast. Vanilla JavaScript: No React, Vue, or Svelte. Pure DOM manipulation and client-side logic. Zero Dependencies: No npm install spiral, no build-step headaches, and zero third-party scripts. No Accounts: Daily state, win streaks, and game progress live in localStorage. MongoDB Atlas: Light backend for aggregate puzzle stats (success rates, guess counts, no PII stored). Hosted on GitHub Pages: Static asset delivery via CDN. Give It a Spin If you like wordplay, geography, or just laughing at terrible tourist complaints, give today's daily puzzle a shot: 👉 Play PunFiction: 1-Star Travel Reviews I’d love to hear your thoughts on the UX, the game feel, or your take on building lightweight web games. Drop your feedback (or your worst pun) in the comments!

Most agent projects do not fail because the first model call is difficult. They become difficult when the prototype needs memory, tools, evaluation, a user interface, documentation that coding agents can navigate, and a repeatable review process. That is the problem the open-source AgentsKit ecosystem is trying to solve for JavaScript teams. It is a set of independent projects with shared contracts, rather than one application that must own the whole stack. The six public pieces 1. AgentsKit: the composable foundation AgentsKit provides focused JavaScript and TypeScript packages for runtimes, adapters, tools, skills, memory, RAG, evaluation, observability, sandboxing, and UI bindings. Its core has zero runtime dependencies and a CI-enforced 10 KB gzipped budget. Six formal contracts keep adapters, tools, memory, retrievers, skills, and runtimes substitutable. You can run a first local agent without an API key: npm install @agentskit/core @agentskit/runtime tsx Then connect OpenAI, Anthropic, Gemini, Ollama, or another adapter without changing the rest of the runtime composition. 2. AgentsKit Chat: one interaction model, seven renderers AgentsKit Chat defines an interactive agent experience once and renders it through React, React Native, Ink, Vue, Svelte, Solid, or Angular. It also supports deterministic local answers before an optional backend call. That matters for documentation and support interfaces where exact project facts should not require an LLM. pnpm dlx @agentskit/chat-cli@0.4.0 init my-chat --renderer react --yes 3. Registry: reusable source, not another dependency The AgentsKit Registry distributes ready-to-use agents in a shadcn-style model: the CLI copies the source into your project, so you can inspect and modify it. npx agentskit add research npx agentskit add code-review The public catalog currently includes research, code-review, and knowledge-promotion agents, and is open to contributions. 4. Agents Playbook: engineering rules that can execute Ag

Most "AI agent" libraries fall into one of two buckets. Either they're a big framework you spend an afternoon configuring, or they're a tiny toy that drops the one feature you actually need in production: the ability to stop and ask a human before the agent does something you can't undo. I wanted the middle. So I wrote yieldagent : a small agent loop you can read end to end, with human-in-the-loop pause/resume built in, and no runtime dependencies. This post walks through how it works and why it's built the way it is. What an agent loop actually is Strip away the branding and an "agent" is a loop: Send the conversation to the model, along with the tools it's allowed to call. If the model asks to call a tool, run it and append the result. Repeat until the model answers without asking for a tool. That's it. The model decides the control flow at runtime; your job is to run the tools and feed the results back. Here's the core, lightly trimmed: for ( let step = 0 ; step < maxSteps ; step ++ ) { const reply = await call ( messages , toolSpecs ); messages . push ( reply ); if ( ! reply . tool_calls ?. length ) { yield { type : " final " , text : reply . content , messages }; return ; } for ( const tc of reply . tool_calls ) { const args = JSON . parse ( tc . function . arguments ); const result = await tools [ tc . function . name ]. run ( args ); messages . push ({ role : " tool " , tool_call_id : tc . id , content : JSON . stringify ( result ) }); } } Everything else in the library is in service of making this loop observable, testable, and safe to run against the real world. Why an async generator Notice the yield . The loop is an async generator, so the caller drives it: for await ( const step of agent ({ call , tools , messages })) { if ( step . type === " tool-start " ) console . log ( " -> " , step . tool , step . args ); if ( step . type === " final " ) console . log ( step . text ); } Every step (each tool call, each result, and the final answer) is handed back to

It started with one simple question: Why am I still doing this manually? I was working on a spreadsheet, checking information row by row, sending emails, and updating statuses. The process was not difficult, but it was repetitive. One small mistake could mean sending incorrect information, overlooking a request, or forgetting to update a row. I knew there had to be an easier way. I wanted the spreadsheet to detect when a status changed to Sent , find the email address in the same row, send the correct message, and add a timestamp after the email was sent. The idea sounded simple in my head. The problem was that I did not know how to build it. I was still learning how to code, so I asked AI for help. My first prompt was something like: Create a script that sends an email from Google Sheets. AI immediately generated a script. It looked impressive, but it did not work the way I expected. The script checked the wrong column, used information from the wrong cells, and failed when some required details were missing. That was when I realized the problem was not only the code. My instructions were too vague. I tried again, but this time I described the entire process: When the status in Column G changes to "Sent," get the email address from Column E and send a confirmation email. After the email is sent successfully, add a timestamp to Column H. Do not send the email if any required information is missing. The result was much closer to what I needed. When I changed the status to Sent and received the email automatically, I felt genuinely excited. It was only a small automation, but it removed several manual steps from the process. After building that first workflow, I started noticing repetitive tasks everywhere. A form submission could automatically send a confirmation email. A spreadsheet could detect missing information before processing a request. A completed action could record the date and time. Reports could be organized without manually copying every row. Tasks that

The bug reports all sounded the same. "It disconnected again." No error, no warning, nothing on screen to explain it. Someone would open a GitHub issue, start a planning-poker vote, then stop to actually read the thing they were estimating. Thirty seconds later they'd look back and the room had quietly gone still. Other people's votes weren't showing up, and their own weren't reaching the room. It had simply stopped, without a word. If you've ever built anything real on Chrome's Manifest V3, you can probably guess where this is going. The socket didn't drop because the network hiccupped. It dropped because Chrome reached over and killed the process it was living in. This is the story of that bug, and what it actually takes to keep a WebSocket alive inside a Manifest V3 extension. TL;DR: Manifest V3 runs your background code in a service worker that Chrome terminates after ~30s idle. If your WebSocket lives there, it dies with it, silently. The fix is three parts: a heartbeat so extension activity keeps the worker awake, auto-reconnect that pulls a fresh snapshot so drops are invisible, and a try/catch around every port message because the worker can die between your null-check and the call. Why the socket doesn't live where you'd expect First, some context on how the extension is wired, because it explains why this bug was even possible. It puts a button on GitHub issues and boards. Click it, and a live planning-poker room opens right there in the page. Votes flow over a WebSocket to a Cloudflare Durable Object that owns the room's state. Standard real-time stuff. The obvious place to open that socket is the content script, the code injected into the GitHub page. That's where the UI lives, so why not open the socket right next to it? Firefox is why not. A content script runs in the page's world, which means it inherits the page's Content Security Policy. GitHub ships a strict connect-src , and Firefox enforces it against content scripts. Try to open wss://… from the