DEV Community: Nightdrive Labs

A game portal rejected my game with one line - "The WASD keys aren't working". They were right, and all my tests were green.

Nightdrive Labs — Sat, 03 Oct 2026 00:53:12 +0000

My browser game Void Parry went to a portal's moderation with dozens of automated browser tests passing. The answer came back a few days later:

The WASD keys aren't working in the game.

That was the whole review. On my machine the keys worked. In every test the keys worked. On the portal's page they did nothing. It took one real key press on the real page to see why, and the cause was a line I wrote on day one.

The line

canvas.addEventListener("pointerdown", (e) => {
  e.preventDefault();          // no text selection, no touch scrolling, no long-press menu
  handlePress(e);
});

Calling preventDefault() on pointerdown is common in canvas games. It also cancels the default action of the press - and one of those defaults is moving keyboard focus to what you clicked.

On my own site that never mattered: the game is the top-level page, the document already has focus, keys arrive.

A portal does not load your game as the top-level page. It puts it in an <iframe> (one portal I checked nests it two frames deep). An iframe only receives key events while it has focus, and it normally gets focus when the player clicks inside it. My handler cancelled exactly that. Pointer events kept arriving - mouse aim and buttons worked, which hid the problem - but keydown went to the portal's page forever.

You can see it in two lines from the devtools console of the game frame:

document.hasFocus()   // false, even right after clicking the game

The first fix was not enough

The obvious repair is to take focus yourself:

canvas.addEventListener("pointerdown", (e) => {
  e.preventDefault();
  window.focus();
  handlePress(e);
});

I verified it on the live page - click, press W A S D, all four arrive - and sent the build back.

Hours later I walked through what the reviewer had actually done, and it was not what I had tested. A new player in my game lands straight in the first boss fight. The mouse only aims; you never have to click. So the reviewer opened the game, pressed W, A, S, D, saw nothing move, and wrote the review. No click ever happened. My fix repaired a path the reporter never took.

A frame is allowed to focus itself without a click, so the real fix has three parts:

window.focus();                                   // when the game loads
function startFight() { window.focus(); /* ... */ }
canvas.addEventListener("pointermove", () => {    // the player is over the game
  if (!document.hasFocus()) window.focus();
});

Plus window.focus() after an ad closes, because an ad overlay takes the keyboard and does not hand it back.

The test I should have had

All my tests loaded index.html directly. The fix for that is small: a host page with the game in an iframe, and a test that never clicks.

fs.writeFileSync("host.html", '<iframe src="index.html" style="width:1280px;height:720px"></iframe>');
fs.writeFileSync("host2.html", '<iframe src="host.html" style="width:1280px;height:720px"></iframe>');

for (const host of ["host.html", "host2.html"]) {          // one and two frames deep
  await page.goto(host);
  const game = page.frames().find((f) => /index\.html/.test(f.url()));
  await game.evaluate(() => { window.keys = []; addEventListener("keydown", (e) => keys.push(e.code)); });

  for (const k of ["KeyW", "KeyA", "KeyS", "KeyD"]) await page.keyboard.press(k);   // no click first
  assert.equal(await game.evaluate(() => keys.join()), "KeyW,KeyA,KeyS,KeyD");
}

It has three cases now: no click at all, the portal page has focus and the player only moves the mouse, and the portal page has focus and the player clicks. The old build fails the first two. Then I ran the same check against the live portal page, because a test page I wrote can share my blind spots.

What it cost

I went back to a second portal that had rejected the game twice, the last time for "overall quality", opened the build they had reviewed in their own preview tool, clicked in the game and pressed the keys. Nothing arrived there either. Two reviews of a keyboard game whose keyboard did not work on their site. I do not know how much of "overall quality" that was. I do know the reviewers could not move.

What I took from it

Test the way the player meets the product. If it ships inside someone else's frame, test it inside a frame. If a new player never clicks, the test must not click.
preventDefault() on pointer events cancels focus too. Keep it if you need it, and take focus yourself.
"Fixed" means the reporter's exact path passes, not a path next to it. Write that path down before you touch the code.
Green tests describe your test page. One manual key press on the real page found in a minute what dozens of tests could not see.

The game and its tests were written with an AI coding assistant; the bug, the review text and the fix are from the real build.

Let the player build the maze - a 576-cell flow field for a tower defense map

Nightdrive Labs — Fri, 02 Oct 2026 07:22:57 +0000

Most tower defense maps give enemies a fixed lane. In one map of Void Parry's tower-defense mode, "Null Grid", there is no lane at all: an open 32x18 grid, an entry on the left, a core on the right, and every tower you place becomes a wall. You build the level. A long route gives your towers more time to shoot, but every wall costs cash you are not spending on damage.

It needs three small pieces of code, and none of them is A*.

1. One distance field, not one path per enemy

Instead of searching a path for each enemy, I compute one distance field from the exit: every free cell stores how far it is from the core. Enemies then just walk "downhill".

export function mazeField(blocked: Uint8Array, exit: number): Float64Array {
  const n = GC * GR, d = new Float64Array(n).fill(Infinity), done = new Uint8Array(n);
  d[exit] = 0;
  for (;;) {   // plain O(n^2) Dijkstra: 576 cells, and it only runs when the maze changes
    let u = -1, best = Infinity;
    for (let i = 0; i < n; i++) if (!done[i] && d[i] < best) { best = d[i]; u = i; }
    if (u < 0) return d;
    done[u] = 1;
    // relax the 8 neighbours (diagonals cost 1.41) ...
  }
}

No priority queue, no heap. With 576 cells the naive version runs in well under a millisecond, and it only runs when a tower is built or sold. I left a comment in the code with the ceiling: a bigger grid would need a real heap.

One detail matters for how it looks: a diagonal step is only allowed if both cells it squeezes between are free. Without that rule, enemies slip through the corner between two towers, and the player reads it as a bug. The same rule also holds in the walker.

2. Walking downhill

Each enemy looks at its 8 neighbours and steps to the one with the lowest distance + step cost. That turns the field into a list of points, and I merge straight runs so the path has few corners. The game already moves enemies along point lists on every other map, so the maze map reuses the normal movement code.

3. Never let the player seal the route

The fun breaks if the player can close the maze completely. So before a tower is placed, a quick breadth-first search runs from the exit with the new cell marked as blocked:

const bl = this.blocked!;
bl[i] = 1;
const ok = mazeOpen(bl, exitCell, [entryCell, ...cellsOfGroundEnemies]);
bl[i] = 0;
return ok ? "" : "block";

It must still reach the entry and every enemy already on the grid. Otherwise you could trap a group of enemies in a pocket. Placing a tower on top of an enemy is refused too. Each refusal returns a reason, so the game can say why ("that would seal the route") instead of silently doing nothing.

Re-routing enemies that are already walking

When a tower goes down, the field is rebuilt once. Then every enemy on the grid gets a new path, starting from its current cell. Enemies still outside the field keep the shared entry path. Flying enemies ignore all of this.

Showing the route before you commit

The first version only showed the new route after you placed a tower, and planning a maze blind is no fun. Now, while you hover a free cell, the game blocks that cell for a moment, rebuilds the lane, and draws it as a dashed yellow line. It only recomputes when the hovered cell (or the maze) changes, so it costs nothing while the pointer rests. A test checks that the preview equals the real route after building.

What's next

Budget the walls. Cheap "barrier" blocks exist so a maze doesn't eat your whole tower budget. Tuning their price is most of the balance work on this map.

The whole feature is about 60 lines of pathfinding. The field approach scales from one enemy to hundreds for the same cost, and "rebuild on change" keeps it simple.

The game and this code were written with an AI coding assistant; the snippets are from the real build.

One build flag, two games - how I shipped a Halloween spin-off from the same codebase

Nightdrive Labs — Thu, 01 Oct 2026 15:38:53 +0000

Playgama is running a weekly challenge called "A Little Spooky": cozy, slightly eerie browser games, no jump scares. I already had a bullet-reflecting boss rush, Void Parry, and a week is not enough to write a second engine. So the spin-off, Hollow Night, is the same code with one flag switched on.

Here is what that looked like in practice.

The flag

The whole switch is one global, set by the build script before the game loads:

<script>window.VP_EVENT = "hollow";</script>
<script src="bosses_hollow.js"></script>

and one line at the top of the game:

const HN = window.VP_EVENT === "hollow";

Everything that differs hangs off HN: the title, the boss list, the arena backgrounds, the music table, the save key and which menus exist. Hollow Night has five bosses and a shop. The main game's other modes are simply not in the zip.

Swap data, not code paths

The rule I kept: HN may pick which data the engine uses, but it should not add new behaviour.

const BG = HN ? ["art/hollow/hollow1_wood.jpg", /* ... */]
              : ["art/bg1_nebula.jpg", /* ... */];

The five new bosses (a lantern wisp, a candle spider, a scarecrow, a grave moth and a smiling moon) re-use bullet pattern families that the main game's tests already cover: spirals, rains, fans, telegraphed lines. Each gets its own palette and one signature move. That way a bot that can beat the main game can also play the spin-off, and I did not need a second test suite.

The boss drawings are a separate file with the same draw API as the main game's. The spin-off's file registers itself under the same name (window.VP_VEC = window.VP_HOLLOW), so the engine's VP_VEC.draw(...) call does not know which file answered.

The build is a short shell script

No bundler. The script copies the files the spin-off needs into a temp folder, rewrites index.html with sed, and zips it:

sed -i -e 's|<script src="bosses_vec.js"></script>|<script>window.VP_EVENT = "hollow";</script>\n<script src="bosses_hollow.js"></script>|' \
       -e 's|<title>Void Parry</title>|<title>Hollow Night</title>|' "$D/index.html"
grep -q 'VP_EVENT = "hollow"' "$D/index.html" && ! grep -q "bosses_vec" "$D/index.html"

The last line matters more than it looks. sed fails silently when its pattern no longer matches. If someone edits the script tag in the main index.html, the build would happily produce a zip of the wrong game. The grep after it turns that into a failed build.

The one thing that must not be shared: the save

Both builds read and write localStorage. On the portal each game gets its own origin, so shared key names would be harmless there. On a test site where both games sit under one origin, the spin-off would load a save with fifteen cleared bosses and menus it does not have.

So the flag also picks the key prefix: the spin-off's saves all start with hn_. When one codebase becomes two products, the save belongs to the product, not to the engine.

What I would do again

One flag, read once, at the top. If you can grep for it, you can count how different the two games are.
Let the variant choose data, not logic. New content rides on tested systems.
Assert after every sed. A text-replace build needs a check that the replace happened.
Separate saves from day one.

Hollow Night is free to play in the browser: playgama.ai/play/qwpaherohe. Five spirits, fog, lanterns, and one button that sends their bullets back.

Made with AI (Claude Code) and published through #PlaygamaMCP; the art is drawn in code, not generated images. #playgama

My game's tutorial said "press R now" - and pressing R did nothing. A bot test found why.

Nightdrive Labs — Wed, 30 Sep 2026 15:35:38 +0000

My browser game Void Parry has one core verb: you reflect enemy bullets back at a boss. The first fight teaches it. A slow white bullet flies at you, time slows down, a ring pulses around your character, and a keycap says R.

The lesson looked fine when I played it, so I thought it worked. Then I wrote a test that plays fight 1 like a new player. It presses R the moment the prompt appears. Often the lesson did not end until its 25-second timeout.

The numbers that didn't line up

Four values, each fine on its own:

Thing	Value
Prompt appears when the bullet is	115 px away
Lesson bullet speed during bullet time	150 px/s × 0.35 ≈ 52 px/s
Reflect bubble lifetime	0.28 s of game time ≈ 0.8 s real time in bullet time
Reflect reach	28 px + bullet radius ≈ 39 px

Press when the prompt appears and the bullet still has 76 px to travel. That takes about 1.5 s real time, and the bubble lasts 0.8 s. The bubble was gone before the bullet arrived. Then the cooldown kicked in (0.9 s of game time, about 2.6 s real time in bullet time), so a second press did nothing either.

A new player learns exactly the wrong lesson here: "the button doesn't work."

Bullet time made it worse, not better. Slowing the world down also slowed my timers down. The prompt fired early by design ("give them time to react"), and the early press missed.

The fix

The fix is two lines. During the lesson only, the reflect lasts three times longer and the cooldown drops to 0.25 s:

const lesson = trainingNow();
P.shieldT  = SH_T * (lesson ? 3 : 1);
P.shieldCd = lesson ? 0.25 : SH_CD;

Now a press on the prompt always catches the bullet. The lesson ends 3-5 s into the game instead of timing out.

The test that caught it

The test drives the real game in headless Chrome with Playwright. It uses real key presses, not by calling the game's functions:

// fresh player: empty localStorage, fight 1 starts on load
const near = await page.evaluate(() => {
  const P = __vp.P;
  return __vp.eb().some(e =>
    Math.hypot(e.x - P.x, e.y - (P.y - 20)) < 75 &&
    (e.x - P.x) * e.vx + (e.y - (P.y - 20)) * e.vy < 0);   // approaching
});
if (near && (Math.random() < 0.7 || lessonBulletOnScreen)) await page.keyboard.press("KeyR");

It then asserts three things:

the lesson ends before 20 s;
fight 1 is won within 35-150 s;
there are at least 8 bullets on screen after the lesson.

That last check exists because an audit had called my first fight "nearly empty".

The same test also showed the fight was too hard for a clumsy bot (four full deaths), so I tuned it with numbers instead of by feel.

Takeaways

Test the tutorial at the moment the prompt appears. Timing windows, slow motion and cooldowns multiply. Each can be right on its own and still be wrong together.
Bullet time slows your own timers too. If you slow the world, check every duration that runs on game time.
A bot doesn't need to be good to be useful. A 70%-accurate bot that moves at random found a bug that my own playtesting walked past.

The game and this test were written with an AI coding assistant; the bug and the numbers are from the real build.

A game portal told me AI art gets rejected, so I redrew 15 bosses in canvas code

Nightdrive Labs — Tue, 29 Sep 2026 15:06:35 +0000

My browser game Void Parry is a neon boss rush: 15 bosses, you reflect their bullets back with a shield. The bosses, backgrounds and key art were painted with an image model and cut out. It looked fine in screenshots.

Then I ran the portal's certification tool. One question was blunt: "Is this game built entirely with generative AI?" I answered yes, because it was. The next screen:

AI for code/logic is welcome, but titles with raw AI graphics are rarely approved.

Their written requirements say why: games with AI graphics perform more than 2x worse on their metrics than games without. Players can tell, and they bounce.

So I replaced every generated image in the game with art drawn by code. It took one evening, and the game looks better for it.

The style: neon line art, drawn every frame

A neon boss rush suits the Geometry Wars / Just Shapes & Beats look: dark shapes, bright outlines, glow. That style is easy to draw with the Canvas 2D API and hard to get wrong:

// one path, stroked four times: wide faint glow, tighter glow, the neon line, a white-hot core
function neon(ctx, path, col, w) {
  ctx.fillStyle = "#0a0616"; path(); ctx.fill();
  ctx.globalCompositeOperation = "lighter";
  ctx.strokeStyle = col + "22"; ctx.lineWidth = w * 6;   path(); ctx.stroke();
  ctx.strokeStyle = col + "4d"; ctx.lineWidth = w * 2.6; path(); ctx.stroke();
  ctx.globalCompositeOperation = "source-over";
  ctx.strokeStyle = col;        ctx.lineWidth = w;       path(); ctx.stroke();
  ctx.strokeStyle = "#ffffffd9"; ctx.lineWidth = w * 0.34; path(); ctx.stroke();
}

No shadowBlur: it is the slow part of canvas glow. Stacked strokes with "lighter" blending look the same and cost almost nothing. The slowest of the 15 bosses draws in 0.33 ms.

Bosses that look back at you

Because each boss is code, it can react. Every draw call gets a small state object:

VP_VEC.draw(ctx, bossIndex, size, time, {
  lx, ly,     // direction to the player, -1..1: eyes and cores follow you
  charge,     // 0..1 while winding up an attack: glows flare, jaws open
  hit,        // flashes the outline white when you land a hit
  phase,      // 1-3: later phases add rings, cracks and more parts
});

The painted sprites could only breathe, lean and move a glow over their eye. Now the Void Eye's pupil tracks you, the Star Leviathan's jaw opens before it fires, and the final boss's chains snap in phase 3. Game feel went up, not just legality.

Backgrounds and covers: procedural, rendered once

Backgrounds don't need to animate, so they are procedural scenes (seeded stars, stacked radial-gradient nebulae, one neon set piece per world: a black hole, a ringed planet, a lava range) rendered once in a headless browser to JPGs. One lesson: dim the set pieces to about 50%. The platforms are neon lines too, and a bright mountain outline behind them reads as something you can stand on.

The key art, store covers and app icon come from one composer page: background + a boss + the hero raising the shield + the title, exported at every size a store asks for.

What I'd tell someone starting out

Use AI for code and game math. That's welcome everywhere I've looked.
If your graphics come out of an image model, expect portals, and players, to hold it against you.
A strong, simple style you can draw in code beats detailed art that looks generic. It also stays consistent: all 15 bosses now look like they belong to one game, which the painted set never did.

The code for the game was written with an AI coding assistant; every visual in it is now drawn by that code.

Cheap bloom for a Canvas 2D game in 8 lines (no WebGL)

Nightdrive Labs — Mon, 28 Sep 2026 22:27:15 +0000

Neon games look flat without bloom: the soft light that bleeds around bright things. The usual advice is "switch to WebGL and write a post-process shader". For my Canvas 2D boss-rush game I wanted the glow without porting the renderer, so I did it with the 2D context itself. The whole pass is 8 lines and costs almost nothing (numbers at the end).

The idea

Bloom is three steps:

Bright pass: keep only the bright pixels.
Blur them.
Add the blurred image back on top of the frame.

Canvas 2D can do all three. ctx.filter takes CSS filter functions (brightness, contrast, blur), and globalCompositeOperation = "lighter" is additive blending. The trick that makes it cheap is doing steps 1-2 on a quarter-resolution canvas: blur is the expensive part, and a 480x270 buffer has 1/16 of the pixels. A blurred image doesn't need resolution anyway.

The code

let bloomC, bloomX;
function applyBloom(cv, cx) {   // call after the world is drawn, before the HUD
  const bw = Math.max(1, cv.width >> 2), bh = Math.max(1, cv.height >> 2);
  if (!bloomC) { bloomC = document.createElement("canvas"); bloomX = bloomC.getContext("2d"); }
  if (bloomC.width !== bw || bloomC.height !== bh) { bloomC.width = bw; bloomC.height = bh; }
  bloomX.globalCompositeOperation = "copy";                                  // replace, don't accumulate
  bloomX.filter = "brightness(0.75) contrast(2.6) blur(3px)";                // bright pass + blur in one go
  bloomX.drawImage(cv, 0, 0, bw, bh); bloomX.filter = "none";
  cx.save(); cx.setTransform(1, 0, 0, 1, 0, 0);
  cx.globalCompositeOperation = "lighter"; cx.globalAlpha = 0.4;             // additive, at 40%
  cx.drawImage(bloomC, 0, 0, cv.width, cv.height); cx.restore();
}

brightness(0.75) contrast(2.6) is the bright pass: contrast pushes mid-greys down to black and bright colours up, so only the neon survives. blur(3px) at quarter resolution is roughly a 12 px blur at full size. Upscaling the small buffer with drawImage adds a bilinear blur for free.

Three things that bit me

Draw order. Apply bloom after the game world and before the HUD. Bloomed text is unreadable, and white UI panels turn into a fog.

Not every browser supports ctx.filter. Safari added it much later than Chrome and Firefox, and a browser without it ignores the property silently: no error, the filter just does nothing, and you add an unblurred copy of the whole frame on top. Everything goes washed out. So test that the feature works instead of checking that the property exists:

const FILTER_OK = (() => { try {
  const a = document.createElement("canvas"), b = document.createElement("canvas");
  a.width = a.height = b.width = b.height = 9;
  const ag = a.getContext("2d"), bg = b.getContext("2d");
  ag.fillStyle = "#fff"; ag.fillRect(4, 4, 1, 1);          // one white pixel
  bg.filter = "blur(2px)"; bg.drawImage(a, 0, 0);
  return bg.getImageData(2, 4, 1, 1).data[3] > 0;         // did it spread two pixels left?
} catch (e) { return false; } })();

Give players a switch. Bloom plus screen flashes is a lot for some people. I put "Glow (bloom)" next to "Reduce flashes" in the settings, and I turn it off automatically when the game's low-quality mode kicks in (frame time above 22 ms for ~2 seconds).

Was it worth it?

With 4x CPU throttling in DevTools the game still ran at 122-145 fps with bloom on, so the cost is negligible next to the game logic. Bullets, parry rings and boss cores went from "coloured dots" to "light". For a small game that's the best visual gain per line of code I've found.

If you've done post-processing in Canvas 2D some other way (for example getImageData loops or OffscreenCanvas in a worker), I'd like to hear how it compared.

You can see the bloom in action in the game it was written for: Void Parry, a free neon boss-rush in the browser (PC and phone).

Written with AI assistance; the code runs in my game.

How to highlight and annotate a PDF in your browser (without uploading it)

Nightdrive Labs — Mon, 28 Sep 2026 17:19:47 +0000

Most "online PDF annotators" upload your file to their servers first. For contracts, research papers or anything private you probably don't want that. Here are the options that keep the PDF on your own computer.

Option 1: the browser's built-in PDF viewer

Firefox has a built-in highlighter: open the PDF, click the highlighter icon in the toolbar, select text, then save with the download button. Your highlights are written into the saved copy.
Edge has Highlight and Draw in its PDF toolbar.
Chrome's viewer has had a basic drawing mode in some versions, but no text highlighter you can count on.

The catch: the highlights live only in the file you save. Close the tab without saving and they are gone, and nothing keeps track of which PDFs you annotated.

Option 2: a highlighter extension that handles web pages and PDFs

I built Glowmark for exactly this: one place for highlights on web pages and in PDFs, stored locally.

Install Glowmark (Firefox; Chrome, Edge and Opera listings are in review).
Right-click a PDF link and choose Open PDF in Glowmark, or use Open a PDF… in its side panel for a file on your computer.
Pick the highlighter, pen or text tool and mark up the PDF.

The annotated copy is saved automatically in your browser and reopens next time; you can still download it. The PDF never leaves your computer, because Glowmark renders it with Mozilla's open-source PDF.js inside the extension. Web page highlighting is free; PDF highlighting is part of Glowmark Pro (7-day free trial).

Option 3: desktop apps

If you annotate PDFs all day, a desktop reader (Okular, Foxit, PDF-XChange, Preview on macOS) is worth it. For quick highlights while you browse, a browser tool is faster.

Disclosure: I'm the developer of Glowmark. Written with AI assistance, tested by hand.

Export web highlights to Obsidian or Notion as Markdown

Nightdrive Labs — Sun, 27 Sep 2026 17:32:14 +0000

If you read on the web and keep notes in Obsidian, Notion or Logseq, copying quotes by hand breaks your flow and loses the source link. A highlighter that exports Markdown turns a page into a note in one click.

Workflow

Highlight text on any page with a highlighter extension (I use my own, Glowmark).
Click a highlight to add your own note.
Open the side panel → Copy as Markdown.
Paste into a new note.

Output

# How note-taking changes memory
https://example.com/article

> Students who wrote notes by hand remembered concepts better a week later.

Check the sample size before citing this.

Title as heading, source link, each highlight as a quote with your note under it. Obsidian and Notion render it as quote blocks.

How the highlights survive page changes

Glowmark stores each highlight as a text quote plus some prefix/suffix context (like the W3C text-quote selector), not as DOM offsets, so highlights re-anchor when a site changes its layout. Everything stays in the browser; nothing is uploaded.

More: https://nightdrivewalls.surge.sh/glowmark/

Written with AI assistance; the extension is mine.

How to recover text you lost in a web form (and never lose it again)

Nightdrive Labs — Sat, 26 Sep 2026 20:31:49 +0000

You wrote a long reply or support ticket, pressed submit, and got "session expired" or a blank page. Before you retype it, try these, fastest first:

Press Back once (Alt+←). Pages restored from the back/forward cache often still have your text in the box. Copy it somewhere safe immediately.
Reopen the closed tab (Ctrl+Shift+T / Cmd+Shift+T). Some sites restore drafts.
Check the site's drafts. Gmail, Outlook, Reddit, WordPress, Discourse and many help desks autosave server-side drafts.
Undo in the empty box (Ctrl+Z) if a script cleared it without reloading the page.
Clipboard history (Win+V on Windows) if you ever copied the text.

The real fix: keep a copy while you type

Form-recovery extensions like Typio and Lazarus used to do this, but they stopped working when Chrome moved to Manifest V3. I built a replacement called Typeback:

saves text boxes, text areas and rich editors (contenteditable) about a second after you stop typing
right-click the empty field → "Restore last draft here" (or Alt+Shift+Z)
100% local (IndexedDB), skips password/card fields and private windows, per-site pause

A few implementation notes for extension devs: one draft per field per page visit (overwritten while typing, so no keystroke spam), restore via document.execCommand("insertText") so undo history and React/Vue state stay intact, and with all_frames only the focused frame answers the "which field?" message.

Details and a test page: https://nightdrivewalls.surge.sh/typeback/

Written with AI assistance; the extension and its tests are mine.