DEV Community: ENKNOT｜TS Dev Lab

My favorite screenshot extension vanished, so I built my own

ENKNOT｜TS Dev Lab — Sat, 12 Sep 2026 02:17:19 +0000

Start dragging, push past the bottom of the window, and the page scrolls along with you. Let go, and you get a single PNG of a region that was never on screen all at once.

The extension I relied on went away

For a long time, GoFullPage was just part of the furniture. Two jobs, mostly:

Screenshotting server maintenance logs for my records (logs are tall)
Capturing a whole page to send to a client

Then one day it stopped working for me. I never dug into exactly what happened — only that something quietly useful wasn't there anymore, with no way to know if it was coming back.

The logs, meanwhile, kept being tall. The clients kept needing pages.

So: fine. I'll build one.

From here to there

It's called Koko Soko (ココソコ). Koko is "here" in Japanese and soko is "there" — you point at one, then the other, and it takes everything in between.

Click the toolbar icon and choose Select Area
Drag out the region you want
It scrolls through your selection, captures it in tiles, and stitches the tiles into one PNG

The auto-scroll at the edges is the entire reason I built this instead of reaching for another full-page tool. You can select a region far larger than one screenful. Capturing and stitching both happen inside the browser; no image is sent anywhere.

There's a Full Page mode too — top to bottom, the thing I'd been using GoFullPage for.

Chrome Web Store:

ココソコ - Koko Soko - Chrome Web Store

ココからソコまで、範囲を指定してスクロールごとスクショ / Capture anything from here to there — select a range and shoot the whole scroll.

chromewebstore.google.com

How it's put together

TypeScript throughout, in three folders:

src/background.ts — the service worker. Calls chrome.tabs.captureVisibleTab, throttles it, retries it. Nothing else.
src/content/ — the selection overlay, coordinate math, tiled capture, canvas stitching, hiding fixed elements while shooting
src/shared/ — utilities shared between background and popup

The only permissions are activeTab and scripting. No standing read/write access to every site you visit.

One build note that's easy to miss: Vite transpiles, it doesn't type-check. A green build tells you nothing about your types. So tsconfig.json sets "noEmit": true and type checking lives in its own script (tsc --noEmit) that I run before committing.

Two things along the way made me stop and go "ah, that's why."

The box that flew away

The first version had a great bug: scroll while you're dragging, and the selection box shoots off across the page.

I was storing the mouse event's coordinates as-is.

// nope
let start = { x: event.clientX, y: event.clientY };

clientX / clientY answer the question "where is this on screen right now" — origin at the top-left of the viewport. Which means they quietly change meaning the instant you scroll. Click 100px from the top, scroll down 200px, and "100px from the top of the screen" now points at a completely different paragraph.

What I actually needed was the position within the document — anchored to the top of the page, unmoved by scrolling. The conversion is just the scroll offset:

// where it appears on screen -> where it lives in the document
toContent(clientX: number, clientY: number): Point {
  return { x: clientX + scrollX, y: clientY + scrollY }
}

// where it lives in the document -> where it appears on screen
toClient(x: number, y: number): Point {
  return { x: x - scrollX, y: y - scrollY }
}

And then one rule, which is really the whole fix: store the selection in content coordinates, convert to client coordinates only at paint time.

function render(): void {
  if (state.kind !== "selecting") return;

  const startClient = state.target.toClient(state.start.x, state.start.y);
  const currentClient = state.target.toClient(state.current.x, state.current.y);

  overlay.setRect({
    top: Math.min(startClient.y, currentClient.y),
    left: Math.min(startClient.x, currentClient.x),
    width: Math.abs(startClient.x - currentClient.x),
    height: Math.abs(startClient.y - currentClient.y),
  });
}

(The Math.min / Math.abs pair is what stops a bottom-right-to-top-left drag from producing a rectangle with negative width.)

That early return is quietly doing double duty. State is a discriminated union — { kind: "idle" } | { kind: "selecting"; start: Point; ... } | { kind: "capturing" } — so once you've bailed out on everything that isn't selecting, TypeScript lets you read state.start. With one flat type full of optional fields, reading selection coordinates mid-capture would have been a runtime bug instead of a red squiggle.

The second click

This one took me the longest.

Koko Soko runs on activeTab, injecting its content script at the moment you click the icon:

chrome.scripting.executeScript({
  target: { tabId }, // which tab
  files: ["content.js"], // what to run
});

That's how you avoid ever holding "read and change everything on every site you visit" — better for store review, and better for the permission dialog people actually read.

And then the second click on the same tab turned the console red.

Uncaught SyntaxError: Identifier 'WindowScrollTarget' has already been declared

What was actually going on

A content script runs in what Chrome calls an isolated world:

An isolated world is a private execution environment that isn't accessible to the page or other extensions.

Private from the page, sure. Not private from me, sixty seconds ago:

First injection → class WindowScrollTarget declared at the top level of that world
Second injection → same declaration, same scope
Collision

A normal page wipes its scope clean on reload. Injection doesn't reload anything, so the first run's leftovers are still sitting there when the second run walks in.

Worth noticing that this is a SyntaxError, not a runtime error. The engine parses the whole file before running a line of it, spots the duplicate name, and throws the file out. You can't try/catch your way out of that — the catch block is inside the file that never ran. Which is why the fix ended up in the build config rather than the code.

Fix one: an IIFE

Emit the content script — and only the content script — as an IIFE.

// vite.content.config.ts
export default defineConfig({
  build: {
    rollupOptions: {
      input: { content: resolve(__dirname, "src/content/index.ts") },
      output: {
        entryFileNames: "[name].js",
        format: "iife", // <- this
      },
    },
    outDir: "dist",
    emptyOutDir: false, // don't wipe the background/popup output
  },
});

The bundle comes out wrapped:

(function () {
  "use strict";
  class WindowScrollTarget {
    /* ... */
  }
})();

A function that runs itself the moment it's defined. Everything declared inside exists only inside. Inject it ten times and you get ten separate scopes that have never met each other, and nothing at all lands in the global one. background.ts and popup.ts stay ordinary ES modules.

Fix two: a flag on `window`

The IIFE stops the collision, but not the execution. Ten scopes means ten passes through the same initialization — ten sets of event listeners hanging off one shared DOM, and one drag firing every one of them.

So I left a marker:

if (!window.__kokosoko__) {
  window.__kokosoko__ = true;

  // everything below runs on the first injection only
  let state: State = { kind: "idle" };
  const overlay = createOverlay();
  // ...register listeners
}

It's tempting to say this works because window is shared. It isn't — the isolated world gets its own window, and window.__kokosoko__ is invisible to the page's own JavaScript.

It works because window outlives the injection. The IIFE scope is built from scratch on every click and remembers nothing; the world's window stays put until you navigate away. Longevity is the only property being used here.

(TypeScript will object that Window has no such member, which declare global and interface declaration merging settle in about four lines.)

So: the IIFE prevents name collisions, the flag prevents duplicate side effects. Two problems wearing one costume.

The seam I left open

Slack, Notion and friends scroll a container rather than the page itself. Koko Soko doesn't handle those yet — the whole thing is built around window.scrollTo().

It is, however, built around it behind an interface:

export interface ScrollTarget {
  getScroll(): Point;
  scrollTo(y: number): void;
  getMaxScrollY(): number;
  getWindowRect(): Rect;
  toContent(clientX: number, clientY: number): Point;
  toClient(x: number, y: number): Point;
  scrollToShowContentAt(y: number): void;
}

There's exactly one implementation today (WindowScrollTarget). Adding an ElementScrollTarget should leave the capture loop and the coordinate math untouched. Premature abstraction is a genuine sin, but when you already know the second implementation is coming, leaving the seam open is just reading ahead.

Wrapping up

This started with something I depended on disappearing, which is an irritating way to start anything. It ended with coordinate systems, a SyntaxError I'd never seen in my life, and a build setting that turned out to be the fix for a bug I'd been trying to solve in code.

If the selection overlay felt suspiciously smooth to write, that's because I'd already built one for ShoText, an extension that OCRs a region of the screen onto your clipboard. Half of this project was me quietly copying myself.

ENKNOT｜TS Dev Lab

Aug 25

I Built a Chrome Extension to Copy Text from YouTube Videos📸

#typescript #javascript #developer #japan

4 min read

If any of that sounds useful, Koko-chan and Soko-chan are available for work.

ココソコ - Koko Soko - Chrome Web Store

ココからソコまで、範囲を指定してスクロールごとスクショ / Capture anything from here to there — select a range and shoot the whole scroll.

chromewebstore.google.com

I Built a Chrome Extension to Copy Text from YouTube Videos📸

ENKNOT｜TS Dev Lab — Tue, 25 Aug 2026 10:23:18 +0000

Why I Built It

When I was studying programming by following along with YouTube tutorials, there was one small but surprisingly annoying task I kept running into.

The person in the video would say:

"Okay, let's move forward with this!"

But then I realized that none of the following were provided anywhere:

Code
System prompts
Other related resources

"こういうやつ" means "this".

So basically, I was thinking:

"Come on, let me copy and paste it, teacher..."

So, I had no choice but to repeat the following process over and over:

Take a screenshot of the relevant part of the video.
Upload it to Claude.
Ask, "Can you transcribe the text in this image?"
Copy and paste the result into VS Code.

...and I had to do this again and again.

Doing this every single time was just way too much of a hassle!

I found myself thinking:

"It would be nice if I could just select part of the screen and copy the text right there."

That was what gave me the idea to try building this Chrome extension.

What I Built

It's a Chrome extension called "ShoText!".

ショッテキ！- ShoText！ - Chrome Web Store

範囲を選択してOCR、結果をクリップボードにコピー / Select an area, OCR it, and copy the text to your clipboard.

chromewebstore.google.com

Here's how it works:

Press Alt+Shift+D and drag to select any area of the screen.
The text within the selected area is automatically extracted using OCR.
The recognized text is automatically copied to the clipboard.

That's it.

For OCR, I use Tesseract.js, the WebAssembly version of Tesseract, and everything is processed locally in the browser. Neither the image nor the OCR results are sent anywhere.

Oh, and about the name "ShoText!":

Taking a screenshot = sounds kind of like "shot!"
文字 (text) = "text" in English, so I went with "Text"

Put them together, and you get "ShoText!"

I hope you'll give it some love.

Born from a One-Shot Prompt by Gemini

Tech Stack

I built it as a monorepo using a pnpm workspace, with two packages:

packages/core
- Common logic that is independent of the browser extension
- Region selection UI
- Image cropping
- Toast notifications
- And more
packages/local-ocr
- The extension itself, using Tesseract.js for local OCR

For the build setup, I use Vite + @crxjs/vite-plugin.

In the following sections, I'd like to share a few "aha!" moments I ran into while building it.

The Problem of Extra Spaces Between Japanese Characters in OCR

When I ran OCR on Japanese text, I ran into a strange problem: a half-width space was inserted between every character.

シ ョ ッ テ キ ！

English worked just fine, so I wondered: why was this happening only with Japanese?

After looking through issues in the official Tesseract repository and asking Claude about it, I found that the preserve_interword_spaces setting was related to the problem.

// Changed from 0 to 1
await worker.setParameters({ preserve_interword_spaces: "1" });

But what exactly is preserve_interword_spaces?

I took a look at the Tesseract source code, and found this:

int numSpaces = preserve_interword_spaces_ ? it_->word()->word->space() : (words_appended > 0);

Hmm... I have absolutely no idea what that means.

So, after digging through issues in the official Tesseract repository and asking Claude to explain it to me, I learned that this setting determines how many spaces should be inserted before a word when constructing the OCR result.

With the default value (0), Tesseract doesn't take into account how much actual space there was between words in the image. Instead, it simply inserts one space between each word.

Internally, Tesseract treats individual characters (or groups of characters) as a single "word." In Japanese text, the gap between adjacent characters is usually close to zero. However, with the default setting, Tesseract ignores the actual spacing and unconditionally inserts one space between each "word."

That's what was causing the extra space between every Japanese character.

By setting preserve_interword_spaces: "1", numSpaces becomes it_->word()->word->space(), which means Tesseract uses the actual amount of spacing detected in the image.

Since the spacing between Japanese characters is usually close to zero, this prevents the unwanted spaces from being inserted.

There might still be some spacing depending on the font—for example, with a monospaced font, extra spaces might appear.

Conclusion

I originally built this Chrome extension to eliminate the small but tedious task of taking screenshots of text from videos and asking Claude to transcribe them. But along the way, I learned a lot about things like the performance characteristics of different libraries, and the differences between OCR models.

I'll keep working to improve my skills.

If you get a chance, give it a try!

ショッテキ！- ShoText！ - Chrome Web Store

範囲を選択してOCR、結果をクリップボードにコピー / Select an area, OCR it, and copy the text to your clipboard.

chromewebstore.google.com

DEV Community: ENKNOT｜TS Dev Lab

My favorite screenshot extension vanished, so I built my own

The extension I relied on went away

From here to there

ココソコ - Koko Soko - Chrome Web Store

How it's put together

The box that flew away

The second click

What was actually going on

Fix one: an IIFE

Fix two: a flag on window

The seam I left open

Wrapping up

I Built a Chrome Extension to Copy Text from YouTube Videos📸

ココソコ - Koko Soko - Chrome Web Store

I Built a Chrome Extension to Copy Text from YouTube Videos📸

Why I Built It

What I Built

ショッテキ！- ShoText！ - Chrome Web Store

Tech Stack

The Problem of Extra Spaces Between Japanese Characters in OCR

Conclusion

ショッテキ！- ShoText！ - Chrome Web Store

Fix two: a flag on `window`