Book 36 · Patriola’s Guide to Claude
Build a Browser Extension
Ship a live price tracker from manifest to Add-ons store. Six unbundled files, one architectural decision per chapter, and a real Firefox extension that passed AMO review — built with Claude, decision by decision.
Six files, no build step, one manifest
Checking a price costs more time than it should — new tab, exchange URL, wait for the page, find the ticker, close the tab. Kaspa Price Watch collapses that into one click: a toolbar popup shows the current KAS/USDT price, a percentage change against the active time window, and a canvas chart built from raw OHLCV klines, with ten selectable ranges from five minutes to one year. A Firefox sidebar panel mirrors the same live data without displacing a tab. It is approved and live on Mozilla Add-ons.
The entire extension lives in six source files — manifest.json, background.js, a popup pair, a sidebar pair, and a shared stylesheet — with nothing compiled or bundled. That matters specifically for an AMO submission, where the reviewer reads your actual source code. Working with Claude, the goal from the start was to keep the dependency surface as small as possible, which turned out to mean eliminating it entirely.
Each chapter is one decision from the real build: which manifest version and why, which exchange API to fetch from, how state moves between the background script, the popup, and the sidebar, and what the AMO submission package actually needs to contain. Nothing here is reconstructed after the fact — the reasoning, the tradeoffs, and the source that shipped are what is documented.
What you’ll learnEvery decision, from manifest to store approval
- The extension model — What a WebExtension actually is, which surfaces it can occupy, and why the manifest sets constraints everything else has to work within.
- Manifest decisions — Manifest V2 versus V3, why Firefox and MV2 were the deliberate starting point, and scoping permissions to two specific API domains instead of a broad host wildcard.
- Picking a data source — Choosing MEXC’s klines endpoint over CoinGecko’s aggregated price, and what a klines response actually gives you for chart rendering.
- The extension lifecycle — Why the background page is three lines, and how a persistent MV2 background differs from what an MV3 service worker would allow.
- Building the popup — Layout, chart canvas, and ten time-range buttons that refetch klines and redraw immediately on selection.
- A chart without a library — Drawing OHLCV data directly to canvas, with no charting dependency shipped in the package.
- The second surface — How the Firefox sidebar panel works as a persistent view alongside your browsing session, sharing data and theme state with the popup.
- Theme and storage — Where a dark/light toggle lives in extension context, and what persists across sessions.
- Store submission — What the AMO review process actually checks, what the zip needs to contain, and how automated review differs from the Chrome Web Store’s longer manual queue.
A preview
A browser extension eliminates every step after clicking the toolbar icon. One click, the price is on screen with a chart. Another click and it disappears — price checked, tab count unchanged, trading interface nowhere to be seen.
Builders who want a real, shipped extension
This book is for readers comfortable with JavaScript and the DOM who want to see a browser extension built and actually approved, not a toy demo. It does not teach a framework or a build tool — the extension ships unbundled, and the book explains why that was the right call. By the end you have a working template for a two-surface extension (popup and sidebar), a canvas chart with no library dependency, and a documented path to porting the same architecture to Chrome MV3.
A longer excerpt is available to newsletter subscribers.
More from Patriola
New books in this series
One short email per book launch.