"chrome://extensions is the front door of extension development. Point dev mode at a folder and Chrome reads it on the spot — no rebuild step, no packaging round-trip. That's why the iteration loop is short."
Where Extensions Get Loaded
Every Chrome extension — whether installed from the Web Store, sideloaded from a developer build, or unpacked from disk — ends up listed on chrome://extensions. That page is Chrome's extension control plane: you toggle, reload, inspect, remove, and watch for errors there.
For development, only one switch matters: Developer mode, top-right corner. Flip it on and three buttons appear — Load unpacked, Pack extension, Update. Of those, Load unpacked is the one that drives the iteration loop.
Load Unpacked: The Three Steps
Starting from the clipdeck/ directory holding the manifest you wrote in Lesson 2:
- Open
chrome://extensions. - Enable Developer mode (top-right toggle).
- Click Load unpacked. Pick the
clipdeck/folder.
Chrome reads manifest.json on the spot. If it parses cleanly, an extension card appears with ID (32 hex chars, derived from your folder's path for unpacked extensions), Name ("ClipDeck"), Version ("0.1.0"), Description, and a Details / Remove / Errors button row. The ClipDeck icon should also appear in the toolbar — though clicking it now goes nowhere, since popup.html doesn't exist yet (Lesson 4's job).
If the manifest fails to parse, a red Errors indicator shows on the card. Click it to see the JSON parse error, the missing field, or the file Chrome couldn't find. Fix the manifest, click the card's reload (↻) button, and Chrome re-reads the directory.
The Reload Button
The reload button is the heart of the dev loop. Any time you edit manifest.json, background.js, popup.html, popup.js, or any other extension file, click reload. Chrome picks up the new files immediately.
Two refresh patterns matter:
- Extension chrome (popup, side panel, background, options page): reload button is enough. Close and reopen the popup; the side panel re-mounts on its next open.
- Content scripts: reload the extension, then also refresh the host pages where the content script was injected. Chrome doesn't retroactively re-inject — content scripts only run on page load.
This second pattern catches everyone exactly once. After you forget it the first time and watch your content-script logs go quiet, the workflow becomes muscle memory.
Update Lifecycle
For Web Store extensions, Chrome checks for updates every few hours and applies them silently. For unpacked extensions, you control the update — the reload button is the update.
Bump version in the manifest from "0.1.0" to "0.2.0" and reload, and Chrome fires chrome.runtime.onInstalled with reason "update". That's the hook for migrations: bump a storage schema, clear stale entries, set up new alarms. Track 2 wires this up; for now, just know the hook exists.
The Errors Panel
Each extension card has an Errors button (visible only when errors exist). Click it to see:
- manifest parse failures
- service worker exceptions (timestamped, with stack traces)
- content script exceptions per page
- permission warnings
The errors panel is sticky — errors accumulate until you clear them or reload. During heavy iteration, clear before each test so only the latest noise is visible.
chrome://extensions in a dedicated tab during development. You'll hit it dozens of times per session; keystrokes to a pinned tab cost less than typing the URL. Cmd+1 through Cmd+9 jumps to pinned tabs by position.ClipDeck Loaded for the First Time
If you followed Lesson 2's exercise, your clipdeck/ folder has manifest.json and three placeholder icons. Loading it now means ClipDeck exists as a real Chrome extension — sandboxed, listed, with a toolbar icon and a stable extension ID. The popup is empty; Lesson 4 fixes that. But the lifecycle is now in your hands: edit, reload, refresh host pages if needed, repeat.