DEV Community: SHOTA

Detecting Which AI Chat Platform You're On: URL and DOM Patterns for ChatGPT, Claude, Gemini, and Copilot

SHOTA — Tue, 30 Jun 2026 16:25:30 +0000

If you're building a Chrome extension that works with AI chat platforms — prompt injection, session export, UI customization — you need to know which platform the user is on before you do anything. A content script that injects a prompt into ChatGPT's textarea will silently fail on Claude, which has a completely different DOM.

Here's how to reliably detect the platform from a content script, with patterns that hold up through UI redesigns.

Matching by URL (Tier 1: Fast and Reliable)

The fastest check: location.hostname. AI platforms use distinct domains with predictable structures:

const AI_PLATFORM_HOSTS = {
  'chatgpt.com': 'chatgpt',
  'chat.openai.com': 'chatgpt',       // legacy domain
  'claude.ai': 'claude',
  'gemini.google.com': 'gemini',
  'copilot.microsoft.com': 'copilot',
  'bard.google.com': 'gemini',        // legacy redirect
  'poe.com': 'poe',
  'character.ai': 'characterai',
};

function detectPlatformByHost() {
  return AI_PLATFORM_HOSTS[location.hostname] ?? null;
}

This covers the common case: user is on claude.ai, hostname matches, platform identified. No DOM access needed.

Edge cases this misses:

Embedded interfaces (ChatGPT embedded in other products)
API playgrounds that aren't the primary chat UI
White-label deployments running on custom domains

For those, fall through to DOM-based detection.

DOM-Based Detection (Tier 2: Layout Signatures)

Each platform has distinctive DOM signatures that are more stable than class names or element IDs (which change frequently). Look for structural patterns, not implementation details:

const PLATFORM_SIGNATURES = [
  {
    platform: 'chatgpt',
    checks: [
      () => !!document.querySelector('[data-testid="send-button"]'),
      () => !!document.querySelector('#prompt-textarea'),
      () => document.title.includes('ChatGPT'),
    ],
  },
  {
    platform: 'claude',
    checks: [
      () => !!document.querySelector('[data-placeholder*="Reply"]'),
      () => !!document.querySelector('.claude-message'),
      () => document.title.toLowerCase().includes('claude'),
    ],
  },
  {
    platform: 'gemini',
    checks: [
      () => !!document.querySelector('rich-textarea'),  // custom element
      () => document.title.includes('Gemini'),
    ],
  },
  {
    platform: 'copilot',
    checks: [
      () => !!document.querySelector('[data-testid="composer-input"]'),
      () => location.hostname.includes('copilot.microsoft.com'),
    ],
  },
];

function detectPlatformByDOM() {
  for (const sig of PLATFORM_SIGNATURES) {
    const passedChecks = sig.checks.filter(fn => {
      try { return fn(); } catch { return false; }
    });
    if (passedChecks.length >= 2) return sig.platform; // majority vote
  }
  return null;
}

The majority vote (requiring at least 2 checks to pass) reduces false positives when only one signature element happens to be present on an unrelated page.

Wrapping each check in try/catch handles DOM state issues — some checks might throw if the element doesn't exist in the way you expect.

Combining Both Approaches

function detectPlatform() {
  // Tier 1: URL-based (instant)
  const byHost = detectPlatformByHost();
  if (byHost) return byHost;

  // Tier 2: DOM-based (for edge cases)
  const byDOM = detectPlatformByDOM();
  return byDOM;
}

In practice, tier 1 handles 95%+ of real usage. Tier 2 is the safety net.

Timing: When to Run Detection

AI chat platforms are SPAs. The initial HTML is usually a shell; the actual UI loads asynchronously. Running detection immediately on document_start will fail — the DOM isn't built yet.

Options:

document_idle injection (simplest):

// manifest.json
"content_scripts": [{
  "matches": ["https://chatgpt.com/*", "https://claude.ai/*", "..."],
  "js": ["content.js"],
  "run_at": "document_idle"
}]

document_idle fires after DOMContentLoaded and after any deferred scripts run, but before images load. For most AI platforms this is sufficient — the UI is rendered by then.

MutationObserver for SPAs:

If the platform changes state after initial load (navigating between conversations, switching models), you need to react to DOM changes:

const observer = new MutationObserver(() => {
  const platform = detectPlatform();
  if (platform && platform !== currentPlatform) {
    currentPlatform = platform;
    onPlatformChanged(platform);
  }
});

observer.observe(document.body, { childList: true, subtree: false });

subtree: false is intentional here — you only need to detect major layout changes, not every DOM mutation inside the conversation thread.

Finding the Input Textarea

Once you know the platform, you need the textarea to inject a prompt:

const INPUT_SELECTORS = {
  chatgpt: [
    '#prompt-textarea',
    'div[contenteditable="true"][data-id="root"]',
  ],
  claude: [
    'div[contenteditable="true"].ProseMirror',
    '[data-placeholder*="Reply to Claude"]',
  ],
  gemini: [
    'rich-textarea .ql-editor',
    'div[contenteditable="true"].textarea',
  ],
  copilot: [
    'textarea[data-testid="composer-input"]',
    'cib-text-input textarea',
  ],
};

function getInputElement(platform) {
  const selectors = INPUT_SELECTORS[platform] ?? [];
  for (const selector of selectors) {
    const el = document.querySelector(selector);
    if (el) return el;
  }
  return null;
}

ContentEditable divs (used by Claude and Gemini) need different injection code than standard textareas:

function injectPrompt(element, text) {
  if (element.tagName === 'TEXTAREA') {
    // Standard textarea
    element.value = text;
    element.dispatchEvent(new Event('input', { bubbles: true }));
  } else if (element.contentEditable === 'true') {
    // ContentEditable (ProseMirror, Quill, etc.)
    element.focus();
    document.execCommand('selectAll', false, null);
    document.execCommand('insertText', false, text);
  }
}

document.execCommand is technically deprecated but remains the most reliable way to trigger React/Vue reactivity on contentEditable elements. The synthetic event approach (new InputEvent('input', { data: text, bubbles: true })) doesn't consistently trigger framework state updates.

Handling Page Navigation in SPAs

ChatGPT and Claude both navigate without page reloads (new conversation = SPA navigation, not a full reload). Your detection logic needs to handle this:

let currentPlatform = detectPlatform();
let lastUrl = location.href;

const navObserver = new MutationObserver(() => {
  if (location.href !== lastUrl) {
    lastUrl = location.href;
    // Re-run detection after navigation
    setTimeout(() => {
      currentPlatform = detectPlatform();
    }, 500); // brief delay for new route to render
  }
});

navObserver.observe(document, { subtree: true, childList: true });

This is the detection layer under PromptStash — a Chrome extension for saving and reusing prompts across AI platforms. One shortcut inserts your saved prompt wherever you are.

What platform-specific quirks have you run into? The Gemini <rich-textarea> custom element was the most surprising — it wraps a Quill editor inside a shadow DOM subtree, which breaks standard querySelector behavior.

Maintaining State Across Separate Screenshots: How Procshot Sequences Steps Automatically

SHOTA — Mon, 29 Jun 2026 16:54:52 +0000

Procshot generates numbered step-by-step guides from browser screenshots. The core mechanic: each screenshot gets a sequence number automatically, so screenshot 1, screenshot 2, screenshot 3 come out labeled without any manual numbering.

The implementation challenge: Chrome screenshots are stateless. Each call to chrome.tabs.captureVisibleTab() is independent. There's no built-in "sequence number" — you have to maintain it yourself across arbitrarily many captures that might happen minutes or hours apart.

Here's how I handle it.

Why Service Worker State Is Not Enough

The obvious approach: keep a let sequenceNumber = 0 in the service worker and increment it on each capture.

// DON'T DO THIS
let sequenceNumber = 0;

chrome.runtime.onMessage.addListener((msg) => {
  if (msg.type === 'CAPTURE') {
    sequenceNumber++;
    captureAndAnnotate(sequenceNumber);
  }
});

MV3 service workers are killed when idle — after 30 seconds with no activity, or when Chrome is under memory pressure. If a user captures screenshot 3, tabs away for two minutes to read something, then comes back for screenshot 4: the service worker has restarted. sequenceNumber is back to 0. Screenshot 4 gets labeled "1".

This was a real bug in early versions. Users capturing a 10-step guide would come back after a break to find the sequence reset mid-guide.

Persisting Sequence State to Storage

The fix: treat sequenceNumber as persisted state, not in-memory state.

async function getNextSequenceNumber(sessionId) {
  const key = `seq_${sessionId}`;
  const result = await chrome.storage.session.get(key);
  const current = result[key] ?? 0;
  const next = current + 1;
  await chrome.storage.session.set({ [key]: next });
  return next;
}

chrome.storage.session persists for the lifetime of the browser session — it survives service worker restarts but clears when Chrome closes. That matches the expected use case: you're capturing a guide in one sitting, not across days.

For cross-session continuity (if someone closes Chrome mid-guide and wants to continue later), swap to chrome.storage.local with explicit session management.

Sessions: When Does Numbering Reset?

Sequence numbering needs to reset when the user starts a new guide. Options:

Timer-based: Reset if more than N minutes have passed since the last capture
Explicit reset: User clicks "New Guide" button
Tab-based: Treat each root URL as a separate guide

Procshot uses option 1 (timer) + option 2 (explicit) together. The timer threshold is configurable (default: 30 minutes). If you're capturing a guide about a 3-page checkout flow, you'll naturally move quickly. If you abandon a capture session for hours, the next capture starts fresh.

const SESSION_TIMEOUT_MS = 30 * 60 * 1000; // 30 minutes default

async function getSessionId() {
  const result = await chrome.storage.session.get(['sessionId', 'lastCaptureAt']);
  const { sessionId, lastCaptureAt } = result;
  const now = Date.now();

  if (!sessionId || !lastCaptureAt || now - lastCaptureAt > SESSION_TIMEOUT_MS) {
    // New session
    const newId = crypto.randomUUID();
    await chrome.storage.session.set({ sessionId: newId, lastCaptureAt: now });
    return newId;
  }

  await chrome.storage.session.set({ lastCaptureAt: now });
  return sessionId;
}

crypto.randomUUID() is available in MV3 service workers without any polyfill.

Annotation: Drawing on Screenshots

captureVisibleTab() returns a PNG as a data URL. To add a step number badge, you need to decode the PNG, draw on it, and re-encode.

This can't be done in the service worker directly — the Canvas API isn't available in service workers (it's a DOM API). The options:

Option A: Offscreen document (MV3 way)

// In service worker
const contexts = await chrome.runtime.getContexts({
  contextTypes: ['OFFSCREEN_DOCUMENT'],
});

if (!contexts.length) {
  await chrome.offscreen.createDocument({
    url: 'offscreen.html',
    reasons: ['CANVAS'],
    justification: 'Annotate screenshot with step number',
  });
}

const result = await chrome.runtime.sendMessage({
  type: 'ANNOTATE',
  screenshotDataUrl,
  stepNumber,
});

The offscreen document is an invisible background page that can use DOM APIs including Canvas. It was added in Chrome 109 specifically for cases like this.

The offscreen annotation logic:

// offscreen.js
chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
  if (msg.type !== 'ANNOTATE') return;

  const img = new Image();
  img.onload = () => {
    const canvas = document.createElement('canvas');
    canvas.width = img.width;
    canvas.height = img.height;
    const ctx = canvas.getContext('2d');
    ctx.drawImage(img, 0, 0);
    drawStepBadge(ctx, msg.stepNumber, img.width);
    sendResponse({ annotated: canvas.toDataURL('image/png') });
  };
  img.src = msg.screenshotDataUrl;
  return true; // async
});

function drawStepBadge(ctx, stepNumber, imgWidth) {
  const BADGE_SIZE = 40;
  const MARGIN = 20;
  const x = MARGIN;
  const y = MARGIN;

  // Circle
  ctx.beginPath();
  ctx.arc(x + BADGE_SIZE / 2, y + BADGE_SIZE / 2, BADGE_SIZE / 2, 0, Math.PI * 2);
  ctx.fillStyle = '#f59e0b'; // amber
  ctx.fill();

  // Number
  ctx.fillStyle = '#ffffff';
  ctx.font = `bold ${BADGE_SIZE * 0.5}px sans-serif`;
  ctx.textAlign = 'center';
  ctx.textBaseline = 'middle';
  ctx.fillText(String(stepNumber), x + BADGE_SIZE / 2, y + BADGE_SIZE / 2);
}

Option B: Content script injection

Inject a content script that creates a canvas overlay on the page, renders the annotation client-side, and sends it back. More complex but works without an offscreen document.

The offscreen document approach is cleaner and is the MV3-idiomatic way.

Download or Export

Once annotated, the screenshots need to reach the user. For a single screenshot: chrome.downloads.download() with a generated filename.

For multi-step export (all screenshots as a ZIP or a generated HTML page), the offscreen document can use the File API to create a Blob, and the service worker can trigger a download of that Blob.

// In service worker, after all steps are captured
async function exportGuide(steps) {
  // steps: [{ stepNumber, annotatedDataUrl, url, timestamp }]
  await chrome.offscreen.createDocument({...});
  const result = await chrome.runtime.sendMessage({
    type: 'EXPORT_HTML',
    steps,
    title: "'My Guide',"
  });
  // result.htmlBlob is a data URL of the generated HTML
  chrome.downloads.download({
    url: result.htmlBlob,
    filename: 'guide.html',
  });
}

The full implementation is in Procshot. It handles session management, annotation, and one-click HTML export — free for up to 5 screenshots per guide, unlimited with Pro.

What's the trickiest part of your screenshot tooling? For me it was the MV3 offscreen document API — the timing between creating the document and sending the first message has some edge cases that took a few iterations to get right.

How to Detect Which Font Is Actually Rendering in a Browser (Not Just the CSS Stack)

SHOTA — Sat, 27 Jun 2026 15:17:35 +0000

getComputedStyle(element).fontFamily returns the CSS declaration: "Hiragino Kaku Gothic ProN", "Yu Gothic", "Noto Sans JP", sans-serif. That's not the font that rendered. It's a priority list. The browser picks the first one that's available and contains a glyph for the character being rendered.

For Latin text, this distinction usually doesn't matter — Windows, macOS, and Linux have converged on a small set of common system fonts. For Japanese, it matters enormously. The visual weight, stroke contrast, and letterform style of Hiragino, Yu Gothic, and Noto Sans JP are genuinely different. A site designed on macOS (where Hiragino is the system Japanese font) looks different on Windows (where Yu Gothic is the fallback).

Here's how to figure out what's actually rendering, and what I learned building Japanese Font Finder to automate it.

Why `getComputedStyle` Doesn't Answer the Question

getComputedStyle(el).fontFamily gives you the cascade result — what the browser received after applying all CSS rules. But it doesn't tell you which entry in the stack was selected.

The underlying question is: does this font exist on this system, and does it have a glyph for this specific character?

For Japanese, both conditions matter. A font might exist on the system but only cover a subset of kanji (common with CJK fonts that split across multiple files). The browser will use that font for characters it covers, and fall back for others.

Canvas-Based Font Detection

The classical technique uses a <canvas> element to measure text rendered with each font in the stack:

function getFallbackWidth(canvas, char) {
  const ctx = canvas.getContext('2d');
  ctx.font = `16px monospace`; // known-available baseline
  return ctx.measureText(char).width;
}

function testFont(fontName, char) {
  const canvas = document.createElement('canvas');
  const ctx = canvas.getContext('2d');
  ctx.font = `16px "${fontName}", monospace`;
  return ctx.measureText(char).width;
}

function isAvailable(fontName, testChar = '中') {
  const canvas = document.createElement('canvas');
  const baseline = getFallbackWidth(canvas, testChar);
  const withFont = testFont(fontName, testChar);
  return withFont !== baseline;
}

The idea: if the font you requested is not available, the browser falls back to monospace. If the width differs from the monospace width, the requested font was used. If it's the same, it wasn't found.

The weakness: fonts can have identical glyph widths for certain characters by coincidence. You need to test multiple characters to reduce false positives, and some edge cases remain.

The `document.fonts` API

Modern browsers expose a CSS Font Loading API that's cleaner for checking font availability:

async function isFontLoaded(fontName) {
  await document.fonts.ready;
  return document.fonts.check(`16px "${fontName}"`);
}

document.fonts.check() returns true if the font is loaded and ready to use. But it has a subtlety: it only considers fonts that have been requested — either via @font-face declarations or because text using that font has actually rendered. System fonts often register as available without needing an explicit load.

For web fonts, you can iterate the loaded FontFaces:

async function getLoadedWebFonts() {
  await document.fonts.ready;
  const fonts = [];
  document.fonts.forEach(face => {
    fonts.push({
      family: face.family,
      weight: face.weight,
      style: face.style,
      status: face.status, // 'loaded' | 'loading' | 'error'
      source: face.toString(), // includes the URL for web fonts
    });
  });
  return fonts;
}

This gives you the web fonts. System fonts won't appear here.

Combining Both Approaches for an Element

To find the actual font rendering on a specific element, you need to:

Get the computed font stack for the element
Parse the font family list
Check each font in order until you find one that's available

function parseComputedFontFamilies(element) {
  const computed = getComputedStyle(element).fontFamily;
  // CSS font-family values can be quoted or unquoted, comma-separated
  return computed.split(',').map(f => f.trim().replace(/^["']|["']$/g, ''));
}

async function resolveActualFont(element) {
  const families = parseComputedFontFamilies(element);

  // First pass: check document.fonts (catches web fonts)
  await document.fonts.ready;
  for (const family of families) {
    if (document.fonts.check(`16px "${family}"`)) {
      return { family, source: 'css-font-loading-api' };
    }
  }

  // Second pass: canvas fingerprinting for system fonts
  const testChar = getTestChar(element); // pick a char from the element's text
  for (const family of families) {
    if (isAvailable(family, testChar)) {
      return { family, source: 'canvas-fingerprint' };
    }
  }

  return { family: families[families.length - 1], source: 'fallback' };
}

For the test character, using a character actually present in the element text gives the most accurate result — a font might have Latin coverage but not CJK coverage.

The Character-Level Problem

Font resolution in browsers is actually per-character, not per-element. A single <p> element mixing Latin and Japanese text might render Latin characters in one font and kanji in another, even within the same font-family declaration.

<p style="font-family: 'Helvetica Neue', 'Hiragino Kaku Gothic ProN', sans-serif;">
  Hello 世界
</p>

"Hello" renders in Helvetica Neue (Latin coverage). "世界" renders in Hiragino Kaku Gothic ProN (Helvetica Neue has no CJK glyphs). Two fonts, one element.

To handle this accurately, you'd need to test per-character range. In practice, JFF uses a heuristic: test with a representative CJK character for Japanese text, and with a Latin character for mixed content.

Content Script Constraints

If you're building this into a Chrome extension content script, a few constraints apply:

Canvas is available: Content scripts can create DOM elements including canvas. No issues.

document.fonts is available: The content script shares the page's window context, so document.fonts reflects fonts loaded on the page.

No access to font files: Content scripts can't read font binary data from the OS or from remote font URLs. You can detect that "Hiragino Kaku Gothic ProN" is rendering, but you can't read the font's metadata from within the content script.

For font metadata: Build a local lookup table. Japanese Font Finder ships a static JSON database of ~300 Japanese fonts with their vendor, category, license type, and commercial links. When a font is identified, it's looked up in the database. No API call required.

The full implementation is in Japanese Font Finder — hover any text on a Japanese page to see the resolved font with metadata. Free on Chrome Web Store.

What's the hairiest font detection edge case you've run into? The character-level fallback mixing is what bit me most — Japanese + emoji in the same element is a particular mess.

Scraping Prices Without an API: Chrome Content Script Patterns for Japanese E-Commerce

SHOTA — Wed, 24 Jun 2026 16:22:13 +0000

Japanese e-commerce is fragmented. The same product — a vintage camera, a game console, a brand bag — can vary by ¥5,000–¥30,000 between Amazon.co.jp, Rakuten, Mercari, and Yahoo! Auctions. Finding the delta requires opening four tabs and cross-referencing manually.

I built Arbitra to automate this. Here's the technical side: how to extract pricing data from multiple sites without official APIs, and the patterns that actually hold up across site redesigns.

The Core Problem with DOM Scraping

API-based price tracking is clean: call an endpoint, parse JSON, done. But Japanese e-commerce platforms don't offer public APIs for real-time pricing. Amazon's Product Advertising API requires active affiliate status, Mercari has no public API, and Rakuten's API lags behind displayed prices.

The alternative: content scripts reading the DOM directly.

The obvious weakness is fragility — sites change their markup and your selectors break. But a few patterns make this survivable.

Selector Strategy: Multiple Candidates with Fallback

Don't bet on a single CSS selector. Use an ordered list of candidates, falling through to the next if the previous returns null:

const PRICE_SELECTORS = {
  amazon: [
    '#corePrice_feature_div .a-price-whole',   // primary product page
    '#priceblock_ourprice',                      // older layout
    '#priceblock_saleprice',
    '.a-price.a-text-price .a-offscreen',       // price in search results
    '#price',
  ],
  mercari: [
    '[data-testid="price"]',                     // React-rendered
    '.item-price',                               // older layout
    'h3.item-price',
    'div[class*="price"] span',
  ],
};

function extractPrice(site) {
  const selectors = PRICE_SELECTORS[site] ?? [];
  for (const selector of selectors) {
    const el = document.querySelector(selector);
    if (el?.textContent?.trim()) {
      return parseJPPrice(el.textContent);
    }
  }
  return null;
}

When Amazon or Mercari redesigns a page section, at least some selectors in the list usually survive.

Parsing Japanese Price Strings

Japanese prices use ¥ or 円, sometimes with commas, sometimes without:

function parseJPPrice(text) {
  // Remove ¥, 円, commas, and whitespace; parse as int
  const cleaned = text.replace(/[¥円,\s]/g, '').trim();
  const num = parseInt(cleaned, 10);
  return isNaN(num) ? null : num;
}

Edge cases to handle:

¥12,800 → 12800
12,800円(税込) → 12800 (strip non-numeric suffix)
¥1,280 (¥160/個) → 1280 (take the first number)
¥– (out of stock marker) → null

Cross-Tab Communication

Content scripts can't directly call each other across tabs. The pattern for "extract price from tab A and send it to tab B":

Content script (producer tab):

chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
  if (request.type === 'EXTRACT_PRICE') {
    const price = extractPrice(request.site);
    sendResponse({ price, url: location.href });
  }
  return true; // async response
});

Service worker (coordinator):

async function getPriceFromTab(tabId, site) {
  return chrome.tabs.sendMessage(tabId, {
    type: 'EXTRACT_PRICE',
    site,
  });
}

// Example: get prices from both open tabs
async function comparePrices(amazonTabId, mercariTabId) {
  const [amazonResult, mercariResult] = await Promise.all([
    getPriceFromTab(amazonTabId, 'amazon'),
    getPriceFromTab(mercariTabId, 'mercari'),
  ]);

  return {
    amazon: amazonResult.price,
    mercari: mercariResult.price,
    delta: (amazonResult.price ?? 0) - (mercariResult.price ?? 0),
  };
}

In MV3, the service worker can be killed and won't be available to process responses. Keep sendMessage round trips short and don't hold open connections.

The Same-Product Problem

Price comparison only matters when you're looking at the same product. Identifying "same product" across Amazon and Mercari is harder than it sounds:

Amazon has ASINs, Mercari has item IDs — no shared identifier
Product names differ: "Sony WH-1000XM5 ヘッドフォンブラック" vs "ソニーヘッドホン WH1000XM5 黒"
Condition varies: new on Amazon, used on Mercari

Arbitra takes the pragmatic route: it identifies the product on the current page and searches for it on the comparison site. Product name extraction from Amazon:

function getAmazonProductTitle() {
  const el =
    document.querySelector('#productTitle') ??
    document.querySelector('.product-title-word-break');
  if (!el) return null;

  // Clean manufacturer suffix — "...ヘッドフォン【国内正規品】" → "...ヘッドフォン"
  return el.textContent.trim().split('【')[0].trim();
}

Then query Mercari search results for that cleaned title and extract the price range from results.

Handling React-Rendered Content

Mercari is a React SPA. Product prices don't exist in the initial HTML — they're injected after hydration. A simple document.ready content script fires too early.

Two options:

Option 1: Retry loop

async function waitForPrice(site, maxWaitMs = 5000) {
  const start = Date.now();
  while (Date.now() - start < maxWaitMs) {
    const price = extractPrice(site);
    if (price !== null) return price;
    await new Promise(r => setTimeout(r, 200));
  }
  return null;
}

Simple but wastes cycles. Fine for a one-shot extraction.

Option 2: MutationObserver

function waitForPriceElement(site) {
  return new Promise((resolve) => {
    const selectors = PRICE_SELECTORS[site] ?? [];

    // Check if already present
    for (const s of selectors) {
      const el = document.querySelector(s);
      if (el?.textContent?.trim()) {
        resolve(parseJPPrice(el.textContent));
        return;
      }
    }

    const observer = new MutationObserver(() => {
      for (const s of selectors) {
        const el = document.querySelector(s);
        if (el?.textContent?.trim()) {
          observer.disconnect();
          resolve(parseJPPrice(el.textContent));
          return;
        }
      }
    });

    observer.observe(document.body, { childList: true, subtree: true });

    // Timeout fallback
    setTimeout(() => {
      observer.disconnect();
      resolve(null);
    }, 5000);
  });
}

More efficient but adds complexity. Worth it for high-frequency extraction.

Site Redesigns and Maintenance

The main maintenance burden: Amazon.co.jp and Mercari both redesign frequently. A few approaches that reduce breakage:

Test selectors against the live site regularly. I run a lightweight scraper check once a week that hits each site and verifies the price selector returns a parseable value.

Use data attributes over class names. Classes like .a-price-whole are more stable than React-generated class names like .sc-abc123. [data-testid="price"] is explicitly placed by developers and tends to survive refactors.

Log extraction failures. When a content script returns null after trying all selectors, send an error event to GA4:

if (price === null) {
  sendGA4Event('price_extraction_failed', {
    site,
    url: location.href.substring(0, 100), // truncate for privacy
  });
}

This gives real user failure data rather than relying on manual testing.

The full extension — cross-referencing prices across Amazon.co.jp, Rakuten Ichiba, Yahoo! Shopping, and Mercari — is available free on the Chrome Web Store:

→ Try Arbitra on Chrome Web Store

What's the most frustrating part of DOM scraping you've dealt with? For me it's infinite scroll on Yahoo! Auctions — the price data is there but pagination makes clean extraction a mess.

Browser Scroll Restoration Is Broken on SPAs. Here's How a Chrome Extension Fixes It.

SHOTA — Mon, 22 Jun 2026 06:45:33 +0000

Chrome has had scroll restoration support since 2015. You can even control it: history.scrollRestoration = 'manual'. But if you've ever tried to reliably restore a user's position on a React or Next.js app, you know it doesn't work the way you'd expect.

Here's what breaks, why it breaks, and how a browser extension can sidestep the entire problem.

What the Browser Actually Does

The default behavior is history.scrollRestoration = 'auto'. When you navigate back to a page, the browser tries to scroll to where you were.

This works fine for static pages. It falls apart for:

SPAs where content is injected into the DOM after navigation
Infinite scroll pages where the content at a given Y position changes depending on what was previously loaded
Lazy-loaded images that push content down after the scroll restore fires

The fundamental problem: the browser fires scroll restoration when the page HTML is parsed, not when the page content is fully rendered. A React app that loads a skeleton → fetches data → renders actual content will restore scroll into a partially-rendered DOM.

The `history.scrollRestoration = 'manual'` Trap

If you set manual, you own scroll restoration completely. Most Next.js apps do this. The typical approach:

// Save position before navigation
router.beforeEach((to, from) => {
  savedPositions[from.path] = window.scrollY;
});

// Restore after navigation
router.afterEach((to) => {
  const position = savedPositions[to.path];
  if (position !== undefined) {
    nextTick(() => window.scrollTo(0, position));
  }
});

The nextTick is the problem. It fires after the Vue/React render cycle, but before async data fetching completes. The page renders empty containers, scroll restores to Y=800, then data loads and pushes everything down. User ends up at Y=800 in a now-different page position.

The correct fix is to wait until the content that was at Y=800 actually exists. There's no clean hook for this — you'd need to observe the DOM until the expected content is present.

How Extensions Can Solve What the Framework Can't

A Chrome extension operates outside the app's JavaScript context. It has access to:

window.scrollY at any point
MutationObserver to detect when DOM content stabilizes
chrome.storage.local to persist positions across sessions without touching the app's state

The approach ReadMark uses:

1. Save position before navigation:

// content script
let lastUrl = location.href;
let saveTimeout;

function savePosition() {
  clearTimeout(saveTimeout);
  saveTimeout = setTimeout(() => {
    const data = {
      url: location.href,
      scrollY: window.scrollY,
      timestamp: Date.now(),
    };
    chrome.storage.local.set({ [location.href]: data });
  }, 500); // debounce: don't save on every pixel
}

window.addEventListener('scroll', savePosition, { passive: true });

The 500ms debounce is important — you don't want to fire a storage write on every scroll event.

2. Detect SPA navigation:

SPAs don't fire load events on navigation. The popstate event fires for back/forward, but not for pushState navigations (clicking a link within an SPA). You need to intercept history.pushState:

const originalPushState = history.pushState.bind(history);
history.pushState = function (...args) {
  originalPushState(...args);
  onUrlChange();
};

window.addEventListener('popstate', onUrlChange);

function onUrlChange() {
  if (location.href !== lastUrl) {
    lastUrl = location.href;
    scheduleRestore();
  }
}

Note: this technique is MV3-compatible as long as it's in the content script, not the service worker. You cannot inject into window from a service worker.

3. Wait for content stability before restoring:

function scheduleRestore() {
  // Wait for initial DOM mutations to settle
  const observer = new MutationObserver(() => {
    clearTimeout(restoreTimeout);
    restoreTimeout = setTimeout(() => {
      observer.disconnect();
      restorePosition();
    }, 150); // 150ms quiescence = content is probably done loading
  });

  observer.observe(document.body, {
    childList: true,
    subtree: true,
  });

  // Fallback if no mutations occur
  setTimeout(() => {
    observer.disconnect();
    restorePosition();
  }, 2000);
}

async function restorePosition() {
  const result = await chrome.storage.local.get(location.href);
  const saved = result[location.href];
  if (saved) {
    window.scrollTo({ top: saved.scrollY, behavior: 'instant' });
  }
}

The MutationObserver approach waits for 150ms of DOM quiescence — no new mutations for 150ms — before restoring. This handles most async data loading patterns without needing app-level hooks.

Why Not Use `sessionStorage`?

Session storage is per-tab and cleared when the tab closes. If you read an article halfway through, close Chrome, and reopen it the next day, the position is gone.

chrome.storage.local persists across sessions. It's also shared across tabs for the same extension (useful if you have the same URL open in multiple tabs and want consistent position).

The downside: storage limits. chrome.storage.local has a 10MB limit by default (but unlimitedStorage permission removes this). For scroll positions (just a URL + Y coordinate + timestamp), 10MB fits tens of thousands of saved positions.

The Multi-Domain Problem

One thing that doesn't generalize: URL key collisions. If you're saving scroll position keyed by location.href, query parameters and hash fragments become part of the key. This is usually correct — example.com/article?page=2 should have a different position than example.com/article?page=1.

But hash-only SPAs where the actual content is the same regardless of hash will accumulate duplicate position entries. Worth handling explicitly if you're building this yourself:

// Normalize URL for storage key
function getKey(url) {
  const u = new URL(url);
  u.hash = ''; // ignore hash if your SPA uses hash routing
  return u.toString();
}

What Actually Works

For apps you control, the cleanest solution is framework-level scroll restoration with a proper content-ready hook. But for third-party sites — documentation, long-form content, GitHub issues, news articles — there's no access to the app's internals.

That's the real use case for extension-based scroll restoration: it works on any site, including ones you don't own and can't modify.

ReadMark is the extension I built for this. Free for up to 5 saved positions, unlimited with Pro.

What approach are you using for scroll restoration on your SPAs? The MutationObserver quiescence pattern has some obvious failure cases (sites that continuously mutate the DOM for animation) — curious what others have run into.

5 Cookie Tricks for Debugging Auth Issues in Chrome (No More Creating Test Accounts)

SHOTA — Mon, 22 Jun 2026 06:42:49 +0000

Debugging authentication in web apps is painful. You need to test the same flow as five different user types — new visitor, returning user, admin, expired session, logged-out — and the easiest way is to constantly create new accounts or clear all your cookies and start over.

There's a faster way. These five techniques use direct cookie manipulation to simulate any auth state without touching your database or creating dummy accounts.

I use CookieJar for most of this — a free Chrome extension built natively on MV3 that gives you a proper UI for cookie editing. But I'll show you the underlying Chrome DevTools method too, so you understand what's actually happening.

1. Simulate a Logged-Out State Without Clearing Everything

The naive approach: clear all cookies and reload. The problem: you just nuked your dev server session token, your local storage flags, your Stripe test mode cookie, and everything else you carefully set up.

The targeted approach: identify and delete only the session/auth cookie.

Most session cookies are named session, sid, auth_token, _session_id, or something close. In DevTools:

Application → Cookies → [your domain] → find the session cookie → right-click → Delete

With CookieJar: open the extension, search session, click the trash icon next to just that cookie.

Your dev environment stays intact. The user state resets to logged-out.

2. Test the "Returning User" vs "New User" Path Without a Second Account

Session cookies tell the server you're authenticated. But many apps use separate cookies to track whether a user has seen the onboarding flow, completed setup, or visited before.

Look for cookies like onboarding_complete, setup_done, first_visit, or custom flags in your app code. To test the new user experience:

Export your current cookies (CookieJar → Export → JSON format, or copy from DevTools)
Delete the specific onboarding/first-visit flag cookie
Reload and test the new user path
Re-import or re-set the cookie to restore your state

This is especially useful when testing progressive disclosure UI — the "have they done X before" branching.

3. Switch Between User Roles Instantly with Cookie Snapshots

If your app uses role-based access control, you'll regularly need to verify that:

Admin users see the admin dashboard
Regular users see the regular dashboard
Guest users see the right landing page

Creating three accounts and logging in/out manually wastes time. The better approach: cookie snapshots.

Setup (one time):

Switching roles (30 seconds):

CookieJar → Import → load admin-session.json → reload
You're now the admin. Test what you need.
Import user-session.json → reload. Now you're the regular user.

This works because the server trusts whoever holds the session token. You're not bypassing auth — you're using valid sessions you legitimately created.

⚠️ Keep these JSON files local and out of version control. They're valid session tokens.

4. Debug "Expired Session" Behavior by Manually Expiring a Cookie

Testing what happens when a session expires is annoying. You either wait for it to actually expire (hours), or you mess with your server-side expiry logic.

The clean way: manipulate the cookie's expiry date directly.

In DevTools:

Application → Cookies → your domain → double-click the Expires column of your session cookie → set it to a past date

With CookieJar: click the cookie → edit the Expiry field → set it to yesterday → save.

Reload the page. The browser now treats the session as expired, and you see exactly what the user sees when their session times out — login redirect, expired session message, or partial UI state.

Reset by importing your saved session snapshot or logging in normally.

5. Find Which Cookie Is Causing a Redirect Loop

Login redirect loops (/login → /dashboard → /login → ...) are almost always caused by a stale or malformed session cookie. The session exists but fails server-side validation.

Systematic isolation approach:

Open CookieJar and look at all cookies for the looping domain
Note every auth-related cookie (look for names containing session, token, auth, jwt)
Delete one at a time, reloading after each deletion
When the loop stops (either you get logged out cleanly or it works), you've found the culprit

This is much faster than clearing all cookies, because it tells you which cookie is broken — useful information for filing a bug report or understanding what's happening server-side.

A common cause: the cookie domain or path is set incorrectly (e.g., set to .example.com but the app is at app.example.com). CookieJar shows you the full cookie metadata including domain, path, Secure, HttpOnly, and SameSite flags — exactly what you need to diagnose this.

What About HttpOnly Cookies?

HttpOnly cookies can't be read or modified by JavaScript, which is the right security choice for session tokens. But Chrome DevTools (and extensions with the cookies permission, like CookieJar) can still see and modify them — because the extension operates at the browser level, not the JavaScript level.

So these techniques work even for HttpOnly session cookies.

The Underlying API

If you want to do this programmatically (in a test script or CI setup), the chrome.cookies API handles all of this:

// Get all cookies for a domain
const cookies = await chrome.cookies.getAll({ domain: 'localhost' });

// Delete a specific cookie
await chrome.cookies.remove({
  url: 'http://localhost:3000',
  name: 'session'
});

// Set a cookie with a specific expiry
await chrome.cookies.set({
  url: 'http://localhost:3000',
  name: 'session',
  value: 'your-valid-session-token',
  expirationDate: Math.floor(Date.now() / 1000) + 3600 // expires in 1 hour
});

For Playwright or Puppeteer testing, you can inject cookies directly into the browser context:

// Playwright
await context.addCookies([{
  name: 'session',
  value: 'test-session-token',
  domain: 'localhost',
  path: '/'
}]);

// Puppeteer
await page.setCookie({
  name: 'session',
  value: 'test-session-token',
  domain: 'localhost'
});

Tools Referenced

Chrome DevTools (built in) — Application tab, manual cookie editing
CookieJar — free Chrome extension for cookie editing, import/export, and privacy scoring. Built on MV3, stores everything locally.

The cookie snapshot workflow (tip #3) is the one I use most. Set it up once, switch user roles in under 30 seconds for the rest of the project.

Browser Scroll Restoration Is Broken on SPAs. Here's How a Chrome Extension Fixes It.

SHOTA — Sun, 21 Jun 2026 15:54:21 +0000

Here's what breaks, why it breaks, and how a browser extension can sidestep the entire problem.

What the Browser Actually Does

The default behavior is history.scrollRestoration = 'auto'. When you navigate back to a page, the browser tries to scroll to where you were.

This works fine for static pages. It falls apart for:

SPAs where content is injected into the DOM after navigation
Infinite scroll pages where the content at a given Y position changes depending on what was previously loaded
Lazy-loaded images that push content down after the scroll restore fires

The `history.scrollRestoration = 'manual'` Trap

If you set manual, you own scroll restoration completely. Most Next.js apps do this. The typical approach:

// Save position before navigation
router.beforeEach((to, from) => {
  savedPositions[from.path] = window.scrollY;
});

// Restore after navigation
router.afterEach((to) => {
  const position = savedPositions[to.path];
  if (position !== undefined) {
    nextTick(() => window.scrollTo(0, position));
  }
});

The correct fix is to wait until the content that was at Y=800 actually exists. There's no clean hook for this — you'd need to observe the DOM until the expected content is present.

How Extensions Can Solve What the Framework Can't

A Chrome extension operates outside the app's JavaScript context. It has access to:

window.scrollY at any point
MutationObserver to detect when DOM content stabilizes
chrome.storage.local to persist positions across sessions without touching the app's state

The approach ReadMark uses:

1. Save position before navigation:

// content script
let lastUrl = location.href;
let saveTimeout;

function savePosition() {
  clearTimeout(saveTimeout);
  saveTimeout = setTimeout(() => {
    const data = {
      url: location.href,
      scrollY: window.scrollY,
      timestamp: Date.now(),
    };
    chrome.storage.local.set({ [location.href]: data });
  }, 500); // debounce: don't save on every pixel
}

window.addEventListener('scroll', savePosition, { passive: true });

The 500ms debounce is important — you don't want to fire a storage write on every scroll event.

2. Detect SPA navigation:

const originalPushState = history.pushState.bind(history);
history.pushState = function (...args) {
  originalPushState(...args);
  onUrlChange();
};

window.addEventListener('popstate', onUrlChange);

function onUrlChange() {
  if (location.href !== lastUrl) {
    lastUrl = location.href;
    scheduleRestore();
  }
}

Note: this technique is MV3-compatible as long as it's in the content script, not the service worker. You cannot inject into window from a service worker.

3. Wait for content stability before restoring:

function scheduleRestore() {
  // Wait for initial DOM mutations to settle
  const observer = new MutationObserver(() => {
    clearTimeout(restoreTimeout);
    restoreTimeout = setTimeout(() => {
      observer.disconnect();
      restorePosition();
    }, 150); // 150ms quiescence = content is probably done loading
  });

  observer.observe(document.body, {
    childList: true,
    subtree: true,
  });

  // Fallback if no mutations occur
  setTimeout(() => {
    observer.disconnect();
    restorePosition();
  }, 2000);
}

async function restorePosition() {
  const result = await chrome.storage.local.get(location.href);
  const saved = result[location.href];
  if (saved) {
    window.scrollTo({ top: saved.scrollY, behavior: 'instant' });
  }
}

The MutationObserver approach waits for 150ms of DOM quiescence — no new mutations for 150ms — before restoring. This handles most async data loading patterns without needing app-level hooks.

Why Not Use `sessionStorage`?

Session storage is per-tab and cleared when the tab closes. If you read an article halfway through, close Chrome, and reopen it the next day, the position is gone.

chrome.storage.local persists across sessions. It's also shared across tabs for the same extension (useful if you have the same URL open in multiple tabs and want consistent position).

The Multi-Domain Problem

But hash-only SPAs where the actual content is the same regardless of hash will accumulate duplicate position entries. Worth handling explicitly if you're building this yourself:

// Normalize URL for storage key
function getKey(url) {
  const u = new URL(url);
  u.hash = ''; // ignore hash if your SPA uses hash routing
  return u.toString();
}

What Actually Works

That's the real use case for extension-based scroll restoration: it works on any site, including ones you don't own and can't modify.

ReadMark is the extension I built for this. Free for up to 5 saved positions, unlimited with Pro.

5 Cookie Tricks for Debugging Auth Issues in Chrome (No More Creating Test Accounts)

SHOTA — Sun, 21 Jun 2026 15:51:36 +0000

There's a faster way. These five techniques use direct cookie manipulation to simulate any auth state without touching your database or creating dummy accounts.

1. Simulate a Logged-Out State Without Clearing Everything

The targeted approach: identify and delete only the session/auth cookie.

Most session cookies are named session, sid, auth_token, _session_id, or something close. In DevTools:

Application → Cookies → [your domain] → find the session cookie → right-click → Delete

With CookieJar: open the extension, search session, click the trash icon next to just that cookie.

Your dev environment stays intact. The user state resets to logged-out.

2. Test the "Returning User" vs "New User" Path Without a Second Account

Session cookies tell the server you're authenticated. But many apps use separate cookies to track whether a user has seen the onboarding flow, completed setup, or visited before.

Look for cookies like onboarding_complete, setup_done, first_visit, or custom flags in your app code. To test the new user experience:

Export your current cookies (CookieJar → Export → JSON format, or copy from DevTools)
Delete the specific onboarding/first-visit flag cookie
Reload and test the new user path
Re-import or re-set the cookie to restore your state

This is especially useful when testing progressive disclosure UI — the "have they done X before" branching.

3. Switch Between User Roles Instantly with Cookie Snapshots

If your app uses role-based access control, you'll regularly need to verify that:

Admin users see the admin dashboard
Regular users see the regular dashboard
Guest users see the right landing page

Creating three accounts and logging in/out manually wastes time. The better approach: cookie snapshots.

Setup (one time):

Switching roles (30 seconds):

CookieJar → Import → load admin-session.json → reload
You're now the admin. Test what you need.
Import user-session.json → reload. Now you're the regular user.

This works because the server trusts whoever holds the session token. You're not bypassing auth — you're using valid sessions you legitimately created.

⚠️ Keep these JSON files local and out of version control. They're valid session tokens.

4. Debug "Expired Session" Behavior by Manually Expiring a Cookie

Testing what happens when a session expires is annoying. You either wait for it to actually expire (hours), or you mess with your server-side expiry logic.

The clean way: manipulate the cookie's expiry date directly.

In DevTools:

Application → Cookies → your domain → double-click the Expires column of your session cookie → set it to a past date

With CookieJar: click the cookie → edit the Expiry field → set it to yesterday → save.

Reload the page. The browser now treats the session as expired, and you see exactly what the user sees when their session times out — login redirect, expired session message, or partial UI state.

Reset by importing your saved session snapshot or logging in normally.

5. Find Which Cookie Is Causing a Redirect Loop

Login redirect loops (/login → /dashboard → /login → ...) are almost always caused by a stale or malformed session cookie. The session exists but fails server-side validation.

Systematic isolation approach:

Open CookieJar and look at all cookies for the looping domain
Note every auth-related cookie (look for names containing session, token, auth, jwt)
Delete one at a time, reloading after each deletion
When the loop stops (either you get logged out cleanly or it works), you've found the culprit

This is much faster than clearing all cookies, because it tells you which cookie is broken — useful information for filing a bug report or understanding what's happening server-side.

What About HttpOnly Cookies?

So these techniques work even for HttpOnly session cookies.

The Underlying API

If you want to do this programmatically (in a test script or CI setup), the chrome.cookies API handles all of this:

// Get all cookies for a domain
const cookies = await chrome.cookies.getAll({ domain: 'localhost' });

// Delete a specific cookie
await chrome.cookies.remove({
  url: 'http://localhost:3000',
  name: 'session'
});

// Set a cookie with a specific expiry
await chrome.cookies.set({
  url: 'http://localhost:3000',
  name: 'session',
  value: 'your-valid-session-token',
  expirationDate: Math.floor(Date.now() / 1000) + 3600 // expires in 1 hour
});

For Playwright or Puppeteer testing, you can inject cookies directly into the browser context:

// Playwright
await context.addCookies([{
  name: 'session',
  value: 'test-session-token',
  domain: 'localhost',
  path: '/'
}]);

// Puppeteer
await page.setCookie({
  name: 'session',
  value: 'test-session-token',
  domain: 'localhost'
});

Tools Referenced

Chrome DevTools (built in) — Application tab, manual cookie editing
CookieJar — free Chrome extension for cookie editing, import/export, and privacy scoring. Built on MV3, stores everything locally.

The cookie snapshot workflow (tip #3) is the one I use most. Set it up once, switch user roles in under 30 seconds for the rest of the project.

5 Cookie Tricks for Debugging Auth Issues in Chrome (No More Creating Test Accounts)

SHOTA — Sat, 20 Jun 2026 15:45:37 +0000

There's a faster way. These five techniques use direct cookie manipulation to simulate any auth state without touching your database or creating dummy accounts.

1. Simulate a Logged-Out State Without Clearing Everything

The targeted approach: identify and delete only the session/auth cookie.

Most session cookies are named session, sid, auth_token, _session_id, or something close. In DevTools:

Application → Cookies → [your domain] → find the session cookie → right-click → Delete

With CookieJar: open the extension, search session, click the trash icon next to just that cookie.

Your dev environment stays intact. The user state resets to logged-out.

2. Test the "Returning User" vs "New User" Path Without a Second Account

Session cookies tell the server you're authenticated. But many apps use separate cookies to track whether a user has seen the onboarding flow, completed setup, or visited before.

Look for cookies like onboarding_complete, setup_done, first_visit, or custom flags in your app code. To test the new user experience:

Export your current cookies (CookieJar → Export → JSON format, or copy from DevTools)
Delete the specific onboarding/first-visit flag cookie
Reload and test the new user path
Re-import or re-set the cookie to restore your state

This is especially useful when testing progressive disclosure UI — the "have they done X before" branching.

3. Switch Between User Roles Instantly with Cookie Snapshots

If your app uses role-based access control, you'll regularly need to verify that:

Admin users see the admin dashboard
Regular users see the regular dashboard
Guest users see the right landing page

Creating three accounts and logging in/out manually wastes time. The better approach: cookie snapshots.

Setup (one time):

Switching roles (30 seconds):

CookieJar → Import → load admin-session.json → reload
You're now the admin. Test what you need.
Import user-session.json → reload. Now you're the regular user.

This works because the server trusts whoever holds the session token. You're not bypassing auth — you're using valid sessions you legitimately created.

⚠️ Keep these JSON files local and out of version control. They're valid session tokens.

4. Debug "Expired Session" Behavior by Manually Expiring a Cookie

Testing what happens when a session expires is annoying. You either wait for it to actually expire (hours), or you mess with your server-side expiry logic.

The clean way: manipulate the cookie's expiry date directly.

In DevTools:

Application → Cookies → your domain → double-click the Expires column of your session cookie → set it to a past date

With CookieJar: click the cookie → edit the Expiry field → set it to yesterday → save.

Reload the page. The browser now treats the session as expired, and you see exactly what the user sees when their session times out — login redirect, expired session message, or partial UI state.

Reset by importing your saved session snapshot or logging in normally.

5. Find Which Cookie Is Causing a Redirect Loop

Login redirect loops (/login → /dashboard → /login → ...) are almost always caused by a stale or malformed session cookie. The session exists but fails server-side validation.

Systematic isolation approach:

Open CookieJar and look at all cookies for the looping domain
Note every auth-related cookie (look for names containing session, token, auth, jwt)
Delete one at a time, reloading after each deletion
When the loop stops (either you get logged out cleanly or it works), you've found the culprit

This is much faster than clearing all cookies, because it tells you which cookie is broken — useful information for filing a bug report or understanding what's happening server-side.

What About HttpOnly Cookies?

So these techniques work even for HttpOnly session cookies.

The Underlying API

If you want to do this programmatically (in a test script or CI setup), the chrome.cookies API handles all of this:

// Get all cookies for a domain
const cookies = await chrome.cookies.getAll({ domain: 'localhost' });

// Delete a specific cookie
await chrome.cookies.remove({
  url: 'http://localhost:3000',
  name: 'session'
});

// Set a cookie with a specific expiry
await chrome.cookies.set({
  url: 'http://localhost:3000',
  name: 'session',
  value: 'your-valid-session-token',
  expirationDate: Math.floor(Date.now() / 1000) + 3600 // expires in 1 hour
});

For Playwright or Puppeteer testing, you can inject cookies directly into the browser context:

// Playwright
await context.addCookies([{
  name: 'session',
  value: 'test-session-token',
  domain: 'localhost',
  path: '/'
}]);

// Puppeteer
await page.setCookie({
  name: 'session',
  value: 'test-session-token',
  domain: 'localhost'
});

Tools Referenced

Chrome DevTools (built in) — Application tab, manual cookie editing
CookieJar — free Chrome extension for cookie editing, import/export, and privacy scoring. Built on MV3, stores everything locally.

The cookie snapshot workflow (tip #3) is the one I use most. Set it up once, switch user roles in under 30 seconds for the rest of the project.

5 Cookie Tricks for Debugging Auth Issues in Chrome (No More Creating Test Accounts)

SHOTA — Fri, 19 Jun 2026 16:31:57 +0000

There's a faster way. These five techniques use direct cookie manipulation to simulate any auth state without touching your database or creating dummy accounts.

1. Simulate a Logged-Out State Without Clearing Everything

The targeted approach: identify and delete only the session/auth cookie.

Most session cookies are named session, sid, auth_token, _session_id, or something close. In DevTools:

Application → Cookies → [your domain] → find the session cookie → right-click → Delete

With CookieJar: open the extension, search session, click the trash icon next to just that cookie.

Your dev environment stays intact. The user state resets to logged-out.

2. Test the "Returning User" vs "New User" Path Without a Second Account

Session cookies tell the server you're authenticated. But many apps use separate cookies to track whether a user has seen the onboarding flow, completed setup, or visited before.

Look for cookies like onboarding_complete, setup_done, first_visit, or custom flags in your app code. To test the new user experience:

Export your current cookies (CookieJar → Export → JSON format, or copy from DevTools)
Delete the specific onboarding/first-visit flag cookie
Reload and test the new user path
Re-import or re-set the cookie to restore your state

This is especially useful when testing progressive disclosure UI — the "have they done X before" branching.

3. Switch Between User Roles Instantly with Cookie Snapshots

If your app uses role-based access control, you'll regularly need to verify that:

Admin users see the admin dashboard
Regular users see the regular dashboard
Guest users see the right landing page

Creating three accounts and logging in/out manually wastes time. The better approach: cookie snapshots.

Setup (one time):

Switching roles (30 seconds):

CookieJar → Import → load admin-session.json → reload
You're now the admin. Test what you need.
Import user-session.json → reload. Now you're the regular user.

This works because the server trusts whoever holds the session token. You're not bypassing auth — you're using valid sessions you legitimately created.

⚠️ Keep these JSON files local and out of version control. They're valid session tokens.

4. Debug "Expired Session" Behavior by Manually Expiring a Cookie

Testing what happens when a session expires is annoying. You either wait for it to actually expire (hours), or you mess with your server-side expiry logic.

The clean way: manipulate the cookie's expiry date directly.

In DevTools:

Application → Cookies → your domain → double-click the Expires column of your session cookie → set it to a past date

With CookieJar: click the cookie → edit the Expiry field → set it to yesterday → save.

Reload the page. The browser now treats the session as expired, and you see exactly what the user sees when their session times out — login redirect, expired session message, or partial UI state.

Reset by importing your saved session snapshot or logging in normally.

5. Find Which Cookie Is Causing a Redirect Loop

Login redirect loops (/login → /dashboard → /login → ...) are almost always caused by a stale or malformed session cookie. The session exists but fails server-side validation.

Systematic isolation approach:

Open CookieJar and look at all cookies for the looping domain
Note every auth-related cookie (look for names containing session, token, auth, jwt)
Delete one at a time, reloading after each deletion
When the loop stops (either you get logged out cleanly or it works), you've found the culprit

This is much faster than clearing all cookies, because it tells you which cookie is broken — useful information for filing a bug report or understanding what's happening server-side.

What About HttpOnly Cookies?

So these techniques work even for HttpOnly session cookies.

The Underlying API

If you want to do this programmatically (in a test script or CI setup), the chrome.cookies API handles all of this:

// Get all cookies for a domain
const cookies = await chrome.cookies.getAll({ domain: 'localhost' });

// Delete a specific cookie
await chrome.cookies.remove({
  url: 'http://localhost:3000',
  name: 'session'
});

// Set a cookie with a specific expiry
await chrome.cookies.set({
  url: 'http://localhost:3000',
  name: 'session',
  value: 'your-valid-session-token',
  expirationDate: Math.floor(Date.now() / 1000) + 3600 // expires in 1 hour
});

For Playwright or Puppeteer testing, you can inject cookies directly into the browser context:

// Playwright
await context.addCookies([{
  name: 'session',
  value: 'test-session-token',
  domain: 'localhost',
  path: '/'
}]);

// Puppeteer
await page.setCookie({
  name: 'session',
  value: 'test-session-token',
  domain: 'localhost'
});

Tools Referenced

Chrome DevTools (built in) — Application tab, manual cookie editing
CookieJar — free Chrome extension for cookie editing, import/export, and privacy scoring. Built on MV3, stores everything locally.

The cookie snapshot workflow (tip #3) is the one I use most. Set it up once, switch user roles in under 30 seconds for the rest of the project.

I Built a Clipboard History Extension. chrome.storage Hit Its Limit. Here's What I Learned.

SHOTA — Wed, 17 Jun 2026 16:54:24 +0000

I built ClipStack to capture and search clipboard history across browser tabs. It worked fine for the first week. Then users with heavy workflows started reporting that their oldest entries were silently disappearing — not on crash, not on refresh, just gone. The extension was eating its own history.

The culprit was chrome.storage.local's 10MB ceiling. Here's how I migrated to IndexedDB, what broke in the process, and what I'd do differently.

The Problem: chrome.storage.local Is Not a Database

chrome.storage.local is convenient — it's synchronous-ish, it syncs changes via listeners, and it requires no setup. But it has two hard limits that matter for a clipboard manager:

10MB total (default) across all keys
8KB per value for chrome.storage.sync (even tighter if you ever need cross-device sync)

For text-only entries, 10MB sounds generous. But clipboard managers often capture:

Rich text (HTML + plain text = 2× storage per entry)
Base64-encoded images (a single screenshot = 1-3MB)
Code blocks with syntax metadata

ClipStack users who copy-paste images or work with long JSON payloads were filling 10MB in under 100 entries. The extension silently dropped the oldest entries to make room — no error, no warning, just vanishing history.

Why IndexedDB

IndexedDB has no practical per-database size limit beyond available disk. Chrome's quota system allocates a percentage of available disk space (typically 60%), which means a device with 100GB free can store 60GB of IndexedDB data. Even for the most clipboard-heavy user, that's irrelevant headroom.

Other advantages that mattered for ClipStack:

Cursor-based iteration: I can page through 10,000 entries without loading them all into memory
Indices: I added an index on timestamp and content_hash for fast dedup lookup
Structured data: Store entries as objects, not JSON-serialized strings

The downside: IndexedDB is callback-based and verbose. I wrapped it in a Promise utility layer to keep the rest of the codebase clean.

The Migration: One-Time on Update

When ClipStack updates from the old version (storage.local) to the new one (IndexedDB), users have existing history. Throwing it away would be a terrible first impression of the upgrade.

The migration runs once on chrome.runtime.onInstalled with reason === 'update':

chrome.runtime.onInstalled.addListener(async ({ reason }) => {
  if (reason !== 'update') return;

  const migrated = await getFlag('idb_migrated');
  if (migrated) return;

  await migrateStorageToIndexedDB();
  await setFlag('idb_migrated', true);
});

The migration reads all entries from storage.local, writes them to IndexedDB in batches, then clears storage.local:

async function migrateStorageToIndexedDB(): Promise<void> {
  const data = await chrome.storage.local.get(null);
  const entries = Object.entries(data)
    .filter(([key]) => key.startsWith('clip_'))
    .map(([_, val]) => val as ClipEntry);

  if (entries.length === 0) return;

  const db = await openDB();
  const tx = db.transaction('clips', 'readwrite');
  const store = tx.objectStore('clips');

  for (const entry of entries) {
    store.put(entry); // Non-blocking within transaction
  }

  await new Promise<void>((resolve, reject) => {
    tx.oncomplete = () => resolve();
    tx.onerror = () => reject(tx.error);
  });

  // Only clear after transaction commits
  await chrome.storage.local.remove(
    entries.map(e => `clip_${e.id}`)
  );
}

The key ordering here: don't remove from storage.local until the IndexedDB transaction commits. If the service worker is killed mid-migration (which can happen in MV3), the old data is still there on next wake.

Service Worker Termination: The Real Challenge

MV3 service workers can be terminated at any time — after 30 seconds of inactivity, when Chrome is under memory pressure, or seemingly at random during development. This creates a problem that doesn't exist in MV2 background pages.

An IndexedDB transaction that hasn't committed yet gets abandoned when the SW dies. Unlike chrome.storage where writes are atomic, IndexedDB writes inside an uncommitted transaction are invisible to readers.

My first version had a bug: I was opening a transaction, writing to it, and awaiting a series of Promises — but if the SW was killed between writes, the transaction would roll back. The entry was "written" from the code's perspective but never visible to readers.

The fix: keep transactions short and commit them immediately after the write:

async function saveClip(entry: ClipEntry): Promise<void> {
  const db = await openDB();

  // One entry = one transaction. Don't batch unless you handle rollback.
  return new Promise((resolve, reject) => {
    const tx = db.transaction('clips', 'readwrite');
    const req = tx.objectStore('clips').put(entry);

    req.onsuccess = () => {};
    tx.oncomplete = () => resolve();
    tx.onerror = () => reject(tx.error);
    tx.onabort = () => reject(new Error('Transaction aborted'));
  });
}

One transaction per entry write. This is slightly less efficient than batching, but it means each write either fully commits or fails cleanly — no half-written state.

Content Dedup With a Hash Index

ClipStack captures clipboard changes via navigator.clipboard.readText() on a polling interval. Without deduplication, copying the same text twice creates two identical entries.

The dedup check needs to be fast — it runs on every clipboard change. I added a content_hash index to the IndexedDB schema:

function upgradeDB(db: IDBDatabase): void {
  const store = db.createObjectStore('clips', { keyPath: 'id' });
  store.createIndex('by_timestamp', 'timestamp', { unique: false });
  store.createIndex('by_hash', 'content_hash', { unique: false });
}

The dedup lookup uses the index to find the most recent entry with the same hash before inserting:

async function isDuplicate(hash: string, windowMs = 5000): Promise<boolean> {
  const db = await openDB();
  const cutoff = Date.now() - windowMs;

  return new Promise((resolve, reject) => {
    const tx = db.transaction('clips', 'readonly');
    const index = tx.objectStore('clips').index('by_hash');
    const range = IDBKeyRange.only(hash);
    const req = index.openCursor(range, 'prev'); // Latest first

    req.onsuccess = () => {
      const cursor = req.result;
      if (!cursor) { resolve(false); return; }
      resolve(cursor.value.timestamp > cutoff);
    };
    req.onerror = () => reject(req.error);
  });
}

The 5-second window avoids treating rapid copy→paste→copy of the same text as a dedup case when the user genuinely wants two separate entries.

Lessons

Don't use chrome.storage.local for unbounded data. It's fine for settings, flags, and small amounts of user-specific state. As soon as the data can grow without a known upper bound, move to IndexedDB from the start.

MV3 SW termination is real. During development the SW stays alive because of DevTools being open. In production, it dies constantly. Any code that holds state across async calls (open transaction + await + more writes) will silently fail on a real user's machine.

One transaction per write is the safe default. Batch writes only after you've proven the performance cost justifies the complexity and you've handled rollback.

Migrate data before removing the old store. Commit to IndexedDB → verify → then clear storage.local. Reversing this order means any interruption results in data loss.

ClipStack is live on the Chrome Web Store — clipboard history that doesn't silently eat itself.

Clipboard Manager & Text Snippets — ClipStack - Chrome Web Store

Auto-save clipboard history, search with Fuse.js, pin clips. Recopy in one click. Free: 20... | Not affiliated with Anthropic, PBC.

chromewebstore.google.com

What storage approach are you using for unbounded extension data? Curious if anyone's tried Cache API as an alternative to IndexedDB.

Built with WXT + TypeScript. IndexedDB wrapper with Promise utilities.

Auto-Block Focus Time in Google Calendar — Building a Schedule-Based Chrome Extension

SHOTA — Tue, 16 Jun 2026 18:29:36 +0000

Most focus-time tools for Google Calendar require OAuth access and sync your calendar data to their servers. Clockwise shut down its free tier. Reclaim is expensive. I wanted something simpler: define quiet hours locally, and have the extension visually block those times on my calendar — no cloud, no account, no data leaving my browser.

That's Quiethours. Here's how it works technically.

Architecture: Pure DOM Overlay

Quiethours doesn't call the Google Calendar API. It injects a content script on calendar.google.com and paints colored overlay blocks directly onto the calendar grid.

Each focus rule stores:

interface FocusRule {
  id: string;
  dayOfWeek: DayOfWeek[];  // [1,2,3,4,5] = Mon–Fri
  startTime: string;        // 'HH:MM' 24h
  endTime: string;
  label: string;
  color: string;            // hex overlay color
  enabled: boolean;
}

Rules live in chrome.storage.local. No server, no OAuth, no calendar scope.

Injecting Overlays on the Calendar Grid

Google Calendar renders a time-slot grid for the day and week views. The content script queries the grid container and injects <div> overlay elements positioned to span the correct time range.

The tricky part is finding the right container across Google Calendar's different views (day, week, month, schedule). I poll for the container with setInterval until it appears — Google Calendar hydrates the DOM asynchronously after navigation:

const waitForCalendar = setInterval(() => {
  const root =
    document.querySelector('[data-view-toggle]') ??
    document.querySelector('div[role="main"]');
  if (root) {
    clearInterval(waitForCalendar);
    observer.observe(root, { childList: true, subtree: false });
    injectOverlays();
  }
}, 500);

subtree: false here matters for performance — watching only the immediate children of the calendar root avoids triggering on every event card render inside the grid.

Reacting to View Changes

Google Calendar is a SPA. When you navigate from week view to day view, the DOM swaps out without a page reload. The MutationObserver detects these changes and re-injects overlays:

const observer = new MutationObserver(() => {
  removeOverlays();
  injectOverlays();
});

removeOverlays() clears all elements tagged with the extension's data attribute before re-injecting. This prevents duplicate overlays when the calendar re-renders existing time slots.

`chrome.alarms` for Periodic Rule Checks

The background service worker runs a 1-minute recurring alarm to check whether a focus block is currently active:

chrome.alarms.create(ALARM_NAME, { periodInMinutes: 1 });

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name !== ALARM_NAME) return;
  const [rules, settings] = await Promise.all([getRules(), getSettings()]);
  const active = getActiveRule(rules);

  if (active && _prevActiveRuleId !== active.id) {
    // Focus block just started
    _prevActiveRuleId = active.id;
    if (settings.notificationsEnabled) {
      chrome.notifications.create({
        type: 'basic',
        iconUrl: chrome.runtime.getURL('icons/icon128.png'),
        title: `🌙 Focus time started`,
        message: `${active.label} — ${active.startTime} to ${active.endTime}`,
      });
    }
    await incrementUsageCount(); // for review-prompt threshold
  } else if (!active && _prevActiveRuleId) {
    // Focus block just ended
    _prevActiveRuleId = null;
  }
});

_prevActiveRuleId is an in-memory variable in the service worker. MV3 service workers can be killed and restarted at any time, so this variable resets on each SW startup. In practice this means the "just started" notification might re-fire after a SW restart if a focus block is already active — acceptable behavior for a 1-minute alarm loop.

Why No OAuth

The most common question: "Why doesn't it read my real calendar events?"

The overlay approach means:

Zero permissions beyond storage and alarms
No https://www.googleapis.com/auth/calendar scope required
Works with any Google Calendar layout without needing API access

The tradeoff: if you have a real meeting during a focus block, the overlay appears over it. That's intentional — the block is semi-transparent so the meeting is still visible underneath.

The 1-Minute Alarm and MV3 Lifecycle

MV3 service workers are terminated when idle. chrome.alarms is one of the few APIs that reliably wakes the SW back up when needed. The 1-minute granularity is fine for this use case — if a focus block starts at 9:00, the notification fires at 9:00 or 9:01 depending on when the alarm last ticked.

For exact-minute precision you'd need the service worker to stay alive or use a content script polling approach. For focus-time reminders, ±1 minute is acceptable.

Install Quiethours from Chrome Web Store →

DEV Community: SHOTA

Detecting Which AI Chat Platform You're On: URL and DOM Patterns for ChatGPT, Claude, Gemini, and Copilot

Matching by URL (Tier 1: Fast and Reliable)

DOM-Based Detection (Tier 2: Layout Signatures)

Combining Both Approaches

Timing: When to Run Detection

Finding the Input Textarea

Handling Page Navigation in SPAs

Maintaining State Across Separate Screenshots: How Procshot Sequences Steps Automatically

Why Service Worker State Is Not Enough

Persisting Sequence State to Storage

Sessions: When Does Numbering Reset?

Annotation: Drawing on Screenshots

Download or Export

How to Detect Which Font Is Actually Rendering in a Browser (Not Just the CSS Stack)

Why getComputedStyle Doesn't Answer the Question

Canvas-Based Font Detection

The document.fonts API

Combining Both Approaches for an Element

The Character-Level Problem

Content Script Constraints

Scraping Prices Without an API: Chrome Content Script Patterns for Japanese E-Commerce

The Core Problem with DOM Scraping

Selector Strategy: Multiple Candidates with Fallback

Parsing Japanese Price Strings

Cross-Tab Communication

The Same-Product Problem

Handling React-Rendered Content

Site Redesigns and Maintenance

Browser Scroll Restoration Is Broken on SPAs. Here's How a Chrome Extension Fixes It.

What the Browser Actually Does

The history.scrollRestoration = 'manual' Trap

How Extensions Can Solve What the Framework Can't

Why Not Use sessionStorage?

The Multi-Domain Problem

What Actually Works

5 Cookie Tricks for Debugging Auth Issues in Chrome (No More Creating Test Accounts)

1. Simulate a Logged-Out State Without Clearing Everything

2. Test the "Returning User" vs "New User" Path Without a Second Account

3. Switch Between User Roles Instantly with Cookie Snapshots

4. Debug "Expired Session" Behavior by Manually Expiring a Cookie

5. Find Which Cookie Is Causing a Redirect Loop

What About HttpOnly Cookies?

The Underlying API

Tools Referenced

Browser Scroll Restoration Is Broken on SPAs. Here's How a Chrome Extension Fixes It.

What the Browser Actually Does

The history.scrollRestoration = 'manual' Trap

How Extensions Can Solve What the Framework Can't

Why Not Use sessionStorage?

The Multi-Domain Problem

What Actually Works

5 Cookie Tricks for Debugging Auth Issues in Chrome (No More Creating Test Accounts)

1. Simulate a Logged-Out State Without Clearing Everything

2. Test the "Returning User" vs "New User" Path Without a Second Account

3. Switch Between User Roles Instantly with Cookie Snapshots

4. Debug "Expired Session" Behavior by Manually Expiring a Cookie

5. Find Which Cookie Is Causing a Redirect Loop

What About HttpOnly Cookies?

The Underlying API

Tools Referenced

5 Cookie Tricks for Debugging Auth Issues in Chrome (No More Creating Test Accounts)

1. Simulate a Logged-Out State Without Clearing Everything

2. Test the "Returning User" vs "New User" Path Without a Second Account

3. Switch Between User Roles Instantly with Cookie Snapshots

4. Debug "Expired Session" Behavior by Manually Expiring a Cookie

5. Find Which Cookie Is Causing a Redirect Loop

What About HttpOnly Cookies?

The Underlying API

Tools Referenced

5 Cookie Tricks for Debugging Auth Issues in Chrome (No More Creating Test Accounts)

1. Simulate a Logged-Out State Without Clearing Everything

2. Test the "Returning User" vs "New User" Path Without a Second Account

3. Switch Between User Roles Instantly with Cookie Snapshots

4. Debug "Expired Session" Behavior by Manually Expiring a Cookie

5. Find Which Cookie Is Causing a Redirect Loop

What About HttpOnly Cookies?

The Underlying API

Tools Referenced

I Built a Clipboard History Extension. chrome.storage Hit Its Limit. Here's What I Learned.

Why `getComputedStyle` Doesn't Answer the Question

The `document.fonts` API

The `history.scrollRestoration = 'manual'` Trap

Why Not Use `sessionStorage`?

The `history.scrollRestoration = 'manual'` Trap

Why Not Use `sessionStorage`?

`chrome.alarms` for Periodic Rule Checks