DEV Community: SHOTA

I Built a Visa Requirement Overlay for Google Flights — Here's How the Chrome Extension Works

SHOTA — Tue, 09 Jun 2026 16:32:24 +0000

Every time I plan a multi-country trip, I end up in the same loop: open the foreign ministry website, navigate three layers of dropdowns, find the right passport/destination combination, then repeat for every country on the itinerary.

There's no reason this should require multiple tabs and five minutes of clicking. So I built EntryCheck — a Chrome extension that injects visa requirement badges directly onto Google Flights results.

The Core Idea

EntryCheck overlays colored status badges on flight destination cards while you browse Google Flights. You set your nationality once in the popup; the extension takes care of the rest.

The five statuses:

🟢 Visa-free — enter without a visa
🟡 Visa on Arrival — get a stamp at the border
🔵 eVisa — apply online before you fly
🟠 Visa required — apply at an embassy
🔴 Not admitted — entry is prohibited

Local JSON Matrix, Zero API Calls

The visa data lives in a local visa-matrix.json file bundled with the extension — 190+ passport/destination combinations, structured as a two-level lookup:

export async function getVisaRequirement(
  passport: string,
  destination: string,
): Promise<VisaRequirement | null> {
  const matrix = await loadVisaMatrix(); // lazy-loaded, cached after first call
  const result = matrix[passport.toUpperCase()]?.[destination.toUpperCase()];
  if (result) return result;
  // EU block: if destination is an EU member, use the EU entry
  if (isEUCountry(destination)) return matrix[passport.toUpperCase()]?.['EU'] ?? null;
  return null;
}

Lazy-loading prevents the 200KB JSON from blocking the content script at startup. The first lookup pays the parse cost; every subsequent lookup hits the cached object.

No external API means no latency, no rate limits, and the extension works offline — useful in airports.

The Hard Part: Google Flights Is a SPA

Google Flights is a single-page app. Destination names appear, change, and disappear without a full page reload, so DOMContentLoaded fires once and then nothing.

The fix is MutationObserver with a 500ms debounce:

const observer = new MutationObserver(() => {
  if (debounceTimer) clearTimeout(debounceTimer);
  debounceTimer = setTimeout(() => injectBadges(nationality), 500);
});
observer.observe(document.body, { childList: true, subtree: true });

Debouncing matters here. Google Flights fires dozens of micro-mutations per second during search animations and autocomplete. Without throttling, you'd call injectBadges() hundreds of times for a single search.

Extracting Destination Text From an Obfuscated DOM

Google's DOM uses auto-generated class names that change between A/B test variants. I use a multi-selector waterfall with a fallback chain:

const selectors = [
  '[jsname="ik4t5"]',           // flight destination text (most stable)
  '[role="listitem"] h2',       // Travel explore cards
  '[role="listitem"] h3',
  '[aria-label*="Flight to"]',  // aria-label match
  '[data-destination-name]',   // data attribute variant
];

Each matched element is tagged with data-entrycheck-injected after processing to skip it on the next observer cycle — otherwise the badge would be re-injected on every DOM mutation.

Country Name → ISO Code

Destination text comes as human-readable names ("Japan", "Paris", "United States"). The visa matrix uses ISO 3166-1 alpha-2 codes ("JP", "FR", "US"). The countryNameToCode function maps between them using a bundled dictionary.

Partial matches help here: Google sometimes shows city names instead of countries ("Tokyo" → "JP", "Paris" → "FR"). The dictionary maps both.

Cleanup

Always disconnect observers when they're no longer needed:

window.addEventListener('unload', () => {
  observer.disconnect();
});

Forgetting this is the most common memory leak in content scripts. With subtree: true watching document.body, a persistent observer accumulates a lot of internal bookkeeping.

Chrome Web Store: https://chromewebstore.google.com/detail/gfbdmeieifamgheecbmdpadniofodkfa

If you book international travel and have ever spent 20 minutes figuring out whether you need a visa, give it a try.

Building a Japanese-First Subscription Tracker PWA (Next.js 15 + Supabase + Serwist)

SHOTA — Wed, 03 Jun 2026 03:26:03 +0000

I built a small PWA called subskunote to solve a very domestic problem: my family's subscriptions were a mess. Netflix was shared, Apple Music was on my kid's own account, a couple of services were under my partner's name, and one I genuinely couldn't remember who was paying for. Per month it looked small. Per year it was over ¥100,000 across 4 people, with no single place to see who pays for what.

Budgeting apps like Money Forward and Zaim already exist and they're great at full household accounting. But I only wanted subscriptions and fixed costs, grouped by person. So I built that one thing.

Here's the stack and the three parts that were actually interesting to build.

The stack

Next.js 15 (App Router, mostly Server Components)
Supabase (Postgres + Auth + RLS)
Stripe (Checkout + Customer Portal, webhooks for subscription state)
Serwist for the service worker (Web Push + offline shell)
Vercel for hosting

Nothing exotic. The interesting parts weren't the framework choices, they were three product details: per-person quota enforcement, payment-method-aware cancel links, and getting Web Push to actually work on iOS.

Part 1: "member slots" and enforcing a freemium quota in the database

The core idea is a member slot: a person label (dad / mom / kid / shared) that subscriptions get attached to. Free users get 3 slots; Pro users get unlimited.

My first instinct was to check the count in the API route before inserting. That works until two requests race each other and you end up with 4 slots on a free plan. So I moved the rule into the database with an RLS-friendly trigger, so the count is enforced where the write actually happens.

-- Block a 4th member slot for free-plan users, atomically
create or replace function subskunote.enforce_member_slot_quota()
returns trigger
language plpgsql
security definer
set search_path = subskunote
as $$
declare
  current_count int;
  user_plan text;
begin
  select plan into user_plan
  from subskunote.profiles
  where id = new.user_id;

  if user_plan = 'pro' then
    return new; -- no limit
  end if;

  select count(*) into current_count
  from subskunote.member_slots
  where user_id = new.user_id;

  if current_count >= 3 then
    raise exception 'FREE_PLAN_SLOT_LIMIT'
      using hint = 'Upgrade to Pro for unlimited member slots';
  end if;

  return new;
end;
$$;

create trigger trg_enforce_member_slot_quota
  before insert on subskunote.member_slots
  for each row execute function subskunote.enforce_member_slot_quota();

The lesson I keep relearning: if a limit matters for billing, it belongs next to the data, not in the handler. RLS guards who can write a row; it doesn't count rows for you. The trigger fills that gap, and the race condition just disappears because the check and the insert are in the same transaction.

One gotcha: don't hardcode 3. I pull the free-tier limit from a config table so I never have the number drift between the SQL, the API, and the UI copy.

Part 2: payment-method-aware cancel links

This is the feature people seem to like most, and it's almost embarrassingly simple.

When you cancel a subscription, where you go depends on how you paid for it. Cancel Netflix that you signed up for with a card? You go to Netflix's site. Subscribed through the App Store? You go to iOS Settings, not Netflix. Google Play, carrier billing — all different.

So subskunote stores the payment method per subscription and resolves the right destination:

type PaymentMethod = "card" | "app_store" | "google_play" | "carrier";

const CANCEL_DESTINATIONS: Record<PaymentMethod, (serviceUrl: string) => string> = {
  card:        (serviceUrl) => serviceUrl,
  app_store:   () => "https://apps.apple.com/account/subscriptions",
  google_play: () => "https://play.google.com/store/account/subscriptions",
  carrier:     () => "", // resolved per carrier below
};

function resolveCancelUrl(sub: Subscription): string {
  const resolver = CANCEL_DESTINATIONS[sub.paymentMethod];
  // always fall back to the service's own page if we don't know better
  return resolver(sub.serviceCancelUrl) || sub.serviceCancelUrl;
}

Note the || sub.serviceCancelUrl fallback. Early on I had CANCEL_DESTINATIONS[method] return undefined for an unmapped method and the "Cancel" button just did nothing. A lookup against user-entered data always needs a default. Now an unknown method degrades gracefully to the service's own cancellation page instead of a dead button.

Part 3: Web Push on iOS without losing your mind

I send renewal reminders 3 days and 1 day before a subscription renews (Web Push plus an email fallback). Deliberately not on the renewal day itself — by then it's too late to act, so the reminder window is "before it renews," not "it renewed."

iOS was the hard part. A few things that cost me time:

Web Push on iOS only works for an installed PWA (added to the Home Screen) on iOS 16.4+. In a regular Safari tab, Notification.requestPermission() won't even prompt. So the UI has to detect standalone mode and tell the user to install first, instead of silently failing.
Subscriptions expire. You'll get 410 Gone from the push service, and if you don't delete that subscription record you'll keep trying forever.

const res = await fetch(pushSubscription.endpoint, { /* ...VAPID-signed... */ });

if (res.status === 410 || res.status === 404) {
  // subscription is dead — remove it so we stop retrying
  await supabase
    .from("push_subscriptions")
    .delete()
    .eq("endpoint", pushSubscription.endpoint);
}

Because iOS Push is unreliable by nature (and requires Home Screen install), email is a first-class fallback, not an afterthought. If push fails or the user never installed, the reminder still lands.

What I'd tell past me

Put billing-relevant limits in the database, not the request handler.
Every lookup against user data needs a fallback value.
On iOS, treat Web Push as best-effort and always have an email path.
Ship the boring 80% (CRUD + auth + Stripe) fast, and spend your real time on the 2-3 details that make the product feel different.

subskunote is live here if you want to poke at it: https://subskunote.dev-tools-hub.xyz

What do you use to keep your own subscriptions from sprawling — a spreadsheet, a budgeting app, or just vibes? Curious how other people handle the "who pays for what" problem.

Auto-Replay Lecture Segments in Your Browser — Building a Chrome Extension for Focused Learning

SHOTA — Tue, 02 Jun 2026 18:06:27 +0000

The standard advice for watching long lecture videos is to take notes. The actual behavior is to watch at 1.5x, zone out for ten minutes, and then re-watch the same section three times. LectureLoop is my attempt to break that pattern.

The extension extracts key points and timestamps from YouTube lectures, displays them in a side panel, and lets you jump directly to any moment in the video. No scrubbing. No re-watching blind.

Getting timestamps out of YouTube

YouTube doesn't expose a public transcript API. But almost every video has auto-generated captions, and the internal timedtext URL is embedded in the page source.

The background service worker fetches the YouTube page, extracts the captionTracks array from ytInitialPlayerResponse, and downloads the XML:

export async function fetchTranscript(videoId: string): Promise<TranscriptSegment[]> {
  const res = await fetch(`https://www.youtube.com/watch?v=${videoId}`, {
    headers: { 'Accept-Language': 'en-US,en;q=0.9' },
  });
  const html = await res.text();

  const match = html.match(/"captionTracks":(\[.*?\])/);
  if (!match) return [];

  const tracks = JSON.parse(match[1]);
  const preferred = tracks.find(t => t.languageCode === 'en' && !t.kind)
    ?? tracks.find(t => t.languageCode === 'en')
    ?? tracks[0];

  const xmlRes = await fetch(preferred.baseUrl);
  const xml = await xmlRes.text();

  const segments: TranscriptSegment[] = [];
  const re = /<text start="([^"]+)" dur="([^"]+)"[^>]*>([\s\S]*?)<\/text>/g;
  let m: RegExpExecArray | null;
  while ((m = re.exec(xml)) !== null) {
    segments.push({
      start: parseFloat(m[1]),
      duration: parseFloat(m[2]),
      text: decodeHtmlEntities(m[3]),
    });
  }
  return segments;
}

The preference order — manual English first, then auto-generated, then first available — matters because auto-captions have worse accuracy for technical vocabulary.

Jumping to a timestamp: the cross-context messaging problem

The side panel and the YouTube tab are different browsing contexts. The side panel can't directly call video.currentTime = n — it doesn't have access to the tab's DOM.

The solution is message passing. The content script registers a listener:

chrome.runtime.onMessage.addListener((msg) => {
  if (msg.type === 'JUMP_TO_TIMESTAMP' && typeof msg.sec === 'number') {
    const video = document.querySelector('video');
    if (video) video.currentTime = msg.sec;
  }
});

The side panel sends the message:

const jumpToTimestamp = (sec: number | null) => {
  if (sec === null) return;
  chrome.tabs.query({ active: true, currentWindow: true }, (tabs) => {
    const tabId = tabs[0]?.id;
    if (tabId) chrome.tabs.sendMessage(tabId, { type: 'JUMP_TO_TIMESTAMP', sec });
  });
};

This avoids chrome.scripting.executeScript, which requires a broader scripting permission. Messaging a pre-registered content script listener needs only tabs — something the extension already requires to read the current video URL.

There's a subtle edge case: content scripts in MV3 can become detached after a page refresh or navigation. If sendMessage fails, the side panel catches the error silently — the user just clicks again.

Tracking navigation on a SPA

YouTube is a single-page app. The content script initializes once, but the user navigates between videos without a page reload.

The approach is a MutationObserver on document.body that detects URL changes:

let lastUrl = location.href;
const navObserver = new MutationObserver(() => {
  if (location.href !== lastUrl) {
    lastUrl = location.href;
    setTimeout(init, 1500); // Wait for YouTube's DOM to settle
  }
});
navObserver.observe(document.body, { childList: true, subtree: true });
window.addEventListener('pagehide', () => navObserver.disconnect(), { once: true });

The 1500ms delay is necessary. YouTube's SPA transitions don't complete synchronously — if you try to inject the button immediately after the URL changes, the target DOM element (#above-the-fold) may not exist yet.

Why chrome.sidePanel instead of a popup

The key learning feature is a list of key points with clickable timestamps. This requires a persistent, non-dismissible UI — something a popup can't provide (it closes when you click away).

Chrome's Side Panel API (chrome.sidePanel) is the right fit. It stays open while the user watches. One wrinkle: content scripts cannot call chrome.sidePanel.open() directly. The content script sends a message to the background service worker, which opens the panel:

// content.ts
btn.addEventListener('click', () => {
  chrome.runtime.sendMessage({ type: 'OPEN_SIDEPANEL', videoId });
});

// background.ts
chrome.runtime.onMessage.addListener((msg, sender) => {
  if (msg.type === 'OPEN_SIDEPANEL' && sender.tab?.windowId) {
    chrome.sidePanel.open({ windowId: sender.tab.windowId });
  }
});

What the extension does

LectureLoop processes YouTube lecture transcripts to extract key points and flashcards, each linked to a timestamp in the video. Clicking a key point jumps you directly to that moment. Flashcards export to Anki format.

Free: 3 videos per month. Pro: unlimited + CSV export.

Available on the Chrome Web Store: https://chromewebstore.google.com/detail/dkfjdnchkngbkeocblinimimiddfnkbg

More Chrome extension builds at dev-tools-hub.xyz.

Building a Japanese-First Read-Later PWA: From Pocket Shutdown to Launch

SHOTA — Thu, 28 May 2026 15:31:28 +0000

When Mozilla shut down Pocket in July 2025, I lost my favorite tool. Worse, none of the English alternatives (Instapaper, Readwise, Matter, Raindrop) had Japanese UI, and their article extraction was mediocre on Japanese pages.

So I built one. It's called Readbox — Japanese-first, English-too, read-later as a PWA. Here's what I learned shipping it.

The stack

Next.js 15 App Router + TypeScript strict (no any)
Supabase (Postgres + Auth + RLS)
Stripe (JPY + USD prices, locale-routed)
Tailwind CSS
Service Worker for PWA install + offline read

Three things that bit me

1. Article extraction on Vercel serverless

First attempt: Mozilla Readability + jsdom. Doesn't bundle on Vercel because of ESM compatibility issues and the 50MB serverless function size limit. I tried 6 approaches — Webpack externals, dynamic imports, edge runtime — none worked cleanly.

Ended up using Jina Reader, which returns clean Markdown/HTML from any URL. Trade-off: third-party dependency, rate limits at scale. But it works today, and it's free.

2. Storing article body on-device

I didn't want to host millions of articles' worth of HTML on Supabase (cost + privacy). Solution: extracted HTML lives in the browser's IndexedDB only (via Dexie); only metadata (URL, title, tags, read status) syncs to the server.

Trade-off: cross-device sync of body content doesn't work seamlessly. Acceptable for a "read it later" workflow where you usually read on the device you saved on.

3. i18n routing — the silent sitemap killer

For Japanese + English from one codebase: app/[locale]/ segment with /en prefix for English (default Japanese has no prefix, to preserve old URLs).

Middleware detects cookie / Accept-Language and redirects accordingly.

The gotcha (cost me a launch-day hour): middleware matcher excludes _next, api, image extensions — but if you forget .xml/.txt/.webmanifest, sitemap.xml and robots.txt get rewritten to /ja/sitemap.xml (which doesn't exist as a route → 404).

Fix:

export const config = {
  matcher: [
    '/((?!api|_next|.*\\.(?:xml|txt|webmanifest|svg|png|jpg|jpeg|gif|webp|ico)$).*)',
  ],
};

If you do i18n routing with metadata routes (sitemap/robots/manifest), put this in your test plan.

Where Readbox is now

Live with paid plans (¥450/mo, $3/mo, free for 100 articles). Pocket CSV import handles both 5-col legacy and 6-col new formats, up to 5,000 articles per batch.

Japanese: https://readbox.dev-tools-hub.xyz/
English: https://readbox.dev-tools-hub.xyz/en

ReadBox — Read-it-later PWA for Pocket refugees

Article text is stored on your device only. 1-click Pocket CSV import. No ads, no tracking — just reading. From $3/month.

readbox.dev-tools-hub.xyz

If you migrated from Pocket, I'd love to hear what your read-later workflow looks like and what made you pick whatever you picked.

I Applied SLA Concepts to My Email Inbox — Here's What I Learned Building the Chrome Extension

SHOTA — Tue, 26 May 2026 17:27:53 +0000

I used to work in B2B SaaS customer support where every incoming email had an SLA timer attached. Green meant you had time, orange meant it was getting close, red meant someone was already frustrated. The system was brutally effective at preventing things from slipping through.

Then I switched jobs and suddenly all those SLA tools were gone. Just an inbox full of emails, no urgency signals, no way to tell at a glance which thread had been waiting the longest.

So I built InboxSLA — a Chrome extension that brings response-time deadlines to Gmail.

The Core Idea

You define clients by email domain and assign each one an SLA in hours. InboxSLA scans your inbox and injects colored badges onto thread rows:

🟢 Green: thread is within SLA (hours remaining shown)
🟠 Orange: approaching the deadline (configurable threshold, default 2h)
🔴 Red "OVERDUE": the clock has run out

The SLA values are fully per-client. A freelancer might set 48h for long-term retainers. An agency handling fast-turnaround support might use 4h.

The Hard Part: Gmail Is a SPA

Gmail doesn't reload the page when you navigate between labels or open threads. The DOM updates in place, which means DOMContentLoaded won't catch anything after the initial load.

The fix is MutationObserver, watching for list changes:

const observer = new MutationObserver(() => {
  scheduleRefresh(); // debounced to 300ms
});
observer.observe(document.body, { childList: true, subtree: true });

The debounce matters a lot. Gmail makes constant small DOM changes while you type in the search box, hover over items, or auto-save a draft. Without throttling, the observer fires hundreds of times per second. I debounce to 300ms and skip re-scans if the thread list container hash hasn't changed.

Extracting Email Metadata From an Obfuscated DOM

Gmail's CSS class names are auto-generated and change between A/B test variants. Rather than trusting class selectors alone, I use a multi-strategy fallback for sender extraction:

const senderEl =
  row.querySelector('[email]') ??
  row.querySelector('.yW span[email]') ??
  row.querySelector('.bA4 span[email]') ??
  row.querySelector('[data-hovercard-id]');

The [email] attribute selector is the most stable — Google uses it internally across many Gmail builds. CSS fallbacks handle variants.

For timestamps, the title attribute on the time element is the most reliable source:

const timeEl =
  row.querySelector('.xW.xY span[title]') ??
  row.querySelector('td.xW span[title]');
const title = timeEl?.getAttribute('title') ?? '';
const parsed = new Date(title).getTime();

Gmail formats this as a full date string ("Mon, Apr 21, 2026, 9:34 AM") in most views. If parsing fails, I fall back to Date.now() — conservative, assumes the thread just arrived. Getting this right across inbox view, All Mail, and search results required handling six different string formats.

Badge Injection Without Breaking Gmail

Two failure modes to guard against when injecting elements into a live SPA you don't own:

Duplicate badges: Gmail sometimes re-renders list items without fully removing them from the DOM. I tag each badge with data-inboxsla-badge and check before injecting:

const BADGE_ATTR = 'data-inboxsla-badge';
let badge = row.querySelector(`[${BADGE_ATTR}]`) as HTMLElement | null;
if (!badge) {
  badge = document.createElement('span');
  badge.setAttribute(BADGE_ATTR, '1');
  row.appendChild(badge);
}
// Update in-place regardless
badge.style.background = bg;
badge.textContent = text;

Stale state: When you open a thread and return to the list, elapsed time has changed. I re-compute badge state on each observer cycle and update style.background and textContent in-place rather than removing and re-injecting — keeps Gmail's own event listeners intact.

MV3: Content Script ↔ Background Service Worker

Client configuration (which domains, which SLA hours) lives in chrome.storage.local. The content script requests it from the background service worker on load and caches locally:

// Content script
const clients = await chrome.runtime.sendMessage({ type: 'GET_CLIENTS' });

// Background SW
chrome.runtime.onMessage.addListener((msg, _sender, respond) => {
  if (msg.type === 'GET_CLIENTS') {
    chrome.storage.local.get('clients').then(({ clients }) => {
      respond(clients ?? []);
    });
    return true; // signal async response
  }
});

The content script re-fetches only after a 5-minute cooldown, not on every mutation. Avoids hammering the background SW with round-trips during heavy DOM activity.

What I'd Do Differently

Gmail's DOM is the main operational risk. Any update Google ships can break selectors. I've already patched once. Long-term, the Gmail Add-ons API would be more stable for thread detection — but it requires OAuth scope approval and a server-side component, which felt like overkill for an MVP.

For now: integration tests against a saved snapshot of Gmail's HTML catch selector regressions before each release.

Chrome Web Store: https://chromewebstore.google.com/detail/inboxsla/fooenikjagbabhodgpohljldfbpggagi

If you manage client email and have ever let a thread sit longer than you meant to, this is for you.

190 Countries, Zero API Calls: Shipping Static Data in a Chrome Extension

SHOTA — Sat, 23 May 2026 15:01:23 +0000

Most Chrome extensions that need data fall into one of two patterns: they call an external API, or they store a small amount of user-specific data locally. EntryCheck does neither. It bundles a static dataset of visa requirements for 190+ passport/destination combinations directly into the extension and resolves every lookup client-side with zero network requests.

This tradeoff — large bundle, instant lookups, no API dependency — turns out to be the right call for travel data. Here's why, and how it works.

Why Static Over API

Visa requirements don't change often. A country might update its visa-on-arrival list two or three times a year. An API would add latency, require authentication, and create a failure mode (network unavailable, API down, rate-limited) in a context where the user is typically trying to quickly check something before booking a flight.

More practically: there's no reliable free public API for visa requirements. The data sources are government websites and reference databases. Scraping or licensing these for a real-time API isn't worth it for a tool whose value is speed and simplicity.

A local JSON file loaded at extension startup sidesteps all of this.

Data Structure

The core dataset is a JSON object keyed by two-letter ISO passport code, then by two-letter destination code:

type VisaStatus =
  | 'visa_free'
  | 'visa_on_arrival'
  | 'e_visa'
  | 'visa_required'
  | 'not_admitted';

interface EntryRequirement {
  status: VisaStatus;
  maxStay?: number;        // days, undefined if no limit
  notes?: string;
}

type VisaMatrix = Record<string, Record<string, EntryRequirement>>;

A lookup is just two array accesses:

function lookup(matrix: VisaMatrix, passport: string, destination: string): EntryRequirement | null {
  return matrix[passport]?.[destination] ?? null;
}

The matrix itself compresses well: visa_free and visa_required cover the majority of combinations, so the JSON has a lot of repeated structure. Gzipped, the full dataset is under 30KB.

Bundling with WXT

The matrix lives in public/visa-matrix.json. WXT (the extension framework) copies the public/ directory to the output root verbatim. The background service worker loads it once on install and caches the result:

let cachedMatrix: VisaMatrix | null = null;

async function getMatrix(): Promise<VisaMatrix> {
  if (cachedMatrix) return cachedMatrix;
  const url = chrome.runtime.getURL('visa-matrix.json');
  const resp = await fetch(url);
  cachedMatrix = await resp.json();
  return cachedMatrix;
}

chrome.runtime.getURL converts the relative path to the extension's internal chrome-extension:// URL. This is the standard pattern for accessing bundled assets from a service worker — it works in MV3 without any special permissions.

Content Script Injection on Google Flights

The lookup popup works fine on its own, but the more useful feature is automatic injection on Google Flights. When a user searches for a flight and the page shows a destination, EntryCheck's content script detects the destination, looks up the requirements for the user's saved passport, and injects a badge next to the search results.

The content script reads the current destination from the URL parameters and page DOM, calls the background for a lookup via chrome.runtime.sendMessage, and renders a small badge component inline.

chrome.runtime.sendMessage(
  { type: 'VISA_LOOKUP', passport: savedPassport, destination: detected },
  (response: EntryRequirement | null) => {
    if (response) renderBadge(response);
  }
);

The background receives this, calls getMatrix(), and returns the result. Because the matrix is in memory after the first load, the response is synchronous from the content script's perspective.

The Maintenance Problem

Static data has one obvious downside: it goes stale. My current approach is to update the JSON file with each extension version bump and push it as a normal CWS update. This is manual but tractable — visa requirements change infrequently enough that quarterly checks cover 95% of changes.

For something that updates more frequently (exchange rates, business hours), this model breaks down and an API makes more sense. Visa requirements are the rare case where static actually wins.

🔗 EntryCheck on Chrome Web Store: Install

How to detect ghost jobs in 2026 — a developer's guide

SHOTA — Wed, 20 May 2026 16:52:37 +0000

I got tired of applying to LinkedIn postings that had been "active 4 days ago" for three months straight. Turns out I wasn't paranoid — the data backs it up. So I built a Chrome extension to flag them, and along the way I worked out how to detect a "ghost job" from inside the browser without hitting any external API. Sharing the playbook here.

The numbers (so you know this isn't rare)

Nearly 4 in 10 hiring managers admit their company has posted jobs with no real plan to fill — Resume Builder 2024 hiring-manager survey, widely reported by WSJ, NYT, and BBC throughout 2024–2025
18% of recruiters say they're actively doing it right now (same survey)
40% of job seekers cite ghost-job frustration as a top complaint (Indeed 2025 candidate sentiment data)
Why it happens: market research, résumé pipeline collection, ATS auto-reposts of already-filled roles, recruiters who quit without removing their open reqs

If you apply to 50 jobs a week and ~40% are ghosts, you're spending around 20 cover letters worth of effort on postings that were never going to convert. At ~12 minutes per tailored application, that's about four hours of your week — every week — burned. Annualized, you're losing two-and-a-half working weeks per year to listings that don't exist.

This is a tractable problem from inside the browser. Here's how.

What "ghost job" actually means

It's not just "a job that didn't reply to me." That's regular job-search reality. A ghost job specifically means one of these:

The role isn't open — posted to pipeline candidates, signal investors the company is growing, or placate an internal stakeholder
The role was open and is now filled, but the posting is still up
The role exists but the hiring manager isn't actively reviewing — auto-rejects only

A good detector doesn't try to read minds. It looks at artifacts of these behaviors that show up in the DOM.

The four signals I use

Signal 1: Posting age

Resume Builder's data puts the median real posting at ~30 days before it's either filled or pulled. Postings still active past 60 days are statistically much more likely to be ghosts.

LinkedIn obfuscates this — it'll show "Posted 4 days ago" even when the underlying post ID has been alive for months. The trick is to parse the <time> element's datetime attribute, not the relative human-readable text.

function getPostingAgeDays(node) {
  const timeEl = node.querySelector('time[datetime]');
  if (!timeEl) return null;
  const posted = new Date(timeEl.getAttribute('datetime'));
  return Math.floor((Date.now() - posted.getTime()) / (1000 * 60 * 60 * 24));
}

If the relative text says "Posted today" but the datetime attribute reads four months ago, that's your first red flag. In my scoring, weight scales linearly past 30 days and hits 2x at 60.

Signal 2: Repost frequency (Levenshtein distance)

Clever recruiters know about the age signal. So they delete a stale posting and re-create it with a new job ID — same description, slightly tweaked title. The relative timestamp resets, the listing looks fresh, and the candidate pool starts over.

You can't catch this with job IDs alone. You need content similarity.

import levenshtein from 'fast-levenshtein';

function isLikelyRepost(currentDescription, historicalDescriptions) {
  for (const past of historicalDescriptions) {
    const distance = levenshtein.get(currentDescription, past);
    const ratio = distance / Math.max(currentDescription.length, past.length);
    if (ratio < 0.05) return true; // <5% character difference = same posting
  }
  return false;
}

Threshold matters. I went with < 5% after testing on ~30 known ghost reposts I'd manually catalogued. <10% gave too many false positives (postings that legitimately got minor edits). <2% missed reposts where the recruiter changed only the location header.

Storage strategy: I keep the last 90 days of descriptions per company in chrome.storage.local with an LRU cap at 1,000 entries. The 10MB quota is plenty for that.

Signal 3: Hidden salary in disclosure-mandatory states

Since 2023, seven US states require salary-range disclosure for any role that could be performed in that state: CA, CO, NY, NJ, WA, MD, RI. (NYC has its own version, and it technically covers any job that could be performed remotely from NYC — which is most knowledge work.)

If a US-targeted posting has no salary range and the company has any operations in those states, that's a real signal. Either:

They're non-compliant (rare for large companies that have legal teams)
The role is targeted at non-covered states only (specific intent — worth checking)
The posting predates the law (which loops back to signal 1)

const DISCLOSURE_STATES = ['CA', 'CO', 'NY', 'NJ', 'WA', 'MD', 'RI'];

function flagMissingSalary(posting) {
  const hasSalary = /\$\d{2,3},?\d{3}/.test(posting.description);
  const inDisclosureState = DISCLOSURE_STATES.some(s =>
    posting.locationHeader.includes(s)
  );
  return inDisclosureState && !hasSalary;
}

Signal 4: Company-level repost rate

If a company has posted 30 roles in the last 6 months and 18 of them have shown age + repost signals, your prior on the next role from that company should be high. This is just Bayesian sanity.

I track this per company in extension storage. After ~10 postings observed per company, the company-level ghost rate becomes a meaningful weight in the score. Below 10 observations, I don't use it — too few samples to be anything but noise.

Putting it together

Final score is a weighted blend, capped at 100:

function ghostScore(posting, history) {
  let score = 0;
  if (posting.ageDays > 60) score += 35;
  else if (posting.ageDays > 30) score += 15;

  if (isLikelyRepost(posting.description, history.descriptions)) score += 25;
  if (flagMissingSalary(posting)) score += 15;
  if (history.companyGhostRate > 0.5) score += 20;
  if (/easy apply/i.test(posting.applyType)) score += 5; // weak signal

  return Math.min(100, score);
}

Bucket the score:

0–30: Likely Real (green)
31–60: Caution (yellow)
61–100: Likely Ghost (red)

These thresholds are arbitrary. I picked them by hand-labelling ~200 postings and tuning until precision on the red bucket sat around 80%. There's no ground truth here — only your tolerance for false positives.

Architecture: MV3, no servers

I wanted this to be 100% client-side. No data leaves the browser, no backend to run, no privacy policy to defend.

content script  →  reads DOM on indeed.com / linkedin.com/jobs / glassdoor.com
       ↓
background SW   →  maintains posting history + company stats in chrome.storage.local
       ↓
popup           →  reads the current job's score and shows the breakdown

The trap I fell into: MV3 service workers go dormant after ~30s of idle. If you're keeping any state in module-level globals, it's gone next time the SW wakes up. Everything has to live in chrome.storage.local. I burned half a day on this — the symptom was scores resetting to "no history" between sessions even though I was clearly calling the store function.

The fix:

// Bad — gone when SW goes dormant
const history = new Map();

// Good — survives dormancy
chrome.storage.local.get(['history'], ({ history = {} }) => {
  // mutate, then write back
  history[companyId] = updated;
  chrome.storage.local.set({ history });
});

Related gotcha: register your event listeners at the top level synchronously. The MV2 "register inside an init callback" pattern silently breaks on MV3 — your listener won't be re-bound when the SW wakes from dormancy, and you'll spend an afternoon wondering why the alarm fires once and never again.

What I'd do differently

Started with two job boards, not three. Maintaining DOM parsers for Indeed, LinkedIn, and Glassdoor is brutal — they each change their layout every 6–8 weeks. If I were starting over I'd ship LinkedIn-only and let user demand drive the second board.
Built the company-level signal first. Per-posting heuristics get noisy. The company-level prior is the thing that actually moves the score meaningfully on repeat offenders — and it's also the signal that gets stronger the longer a user has the extension installed. That's the right kind of moat.
Skipped Levenshtein initially. Useful but expensive — I underestimated how often I'd hit chrome.storage.local on a single page render. For ~1,000-entry history it's fine; if you push past that you'll want a cheap hash-based similarity pre-filter (e.g., shingling) before paying for full Levenshtein.

The product

I shipped this as GhostJob on the Chrome Web Store:

→ https://chromewebstore.google.com/detail/ghostjob/mdjchaohgneaiflafheajamfomeccach

Free for 10 scans/day, with the full score breakdown and recent-checks history. Pro is $6/month or $59 lifetime — unlimited checks, salary insights backed by the public US Bureau of Labor Statistics API, and priority support. Currently scores Indeed, LinkedIn, and Glassdoor postings. English UI is shipping next week (5/29), and the Levenshtein repost-detection update lands the week after (6/5).

If you want to skip the read-and-build path and just use it, that link is the fastest way. If you'd rather take the four signals above and roll your own, that works too — that's why I wrote the post. The hard part of this problem isn't the algorithm. It's keeping the DOM parsers alive against three companies that each rev their job-search UI on a different cadence. If you're going to maintain that yourself, budget for it.

Question for you

What signal am I missing? "Easy Apply" without a follow-up flow is on my list but I haven't tuned its weight enough to commit. Same with recruiter profile age and number of currently-open reqs per recruiter — both feel signal-bearing but I can't isolate them from the company-level signal cleanly yet.

If you've shipped anything in this space — or just have strong opinions about what makes a posting feel like a ghost — drop it in the comments.

What do you use to filter your job search?

Ghost Jobs Are Wasting Your Time — I Built a Chrome Extension to Detect Them

SHOTA — Tue, 19 May 2026 16:51:32 +0000

A ghost job is a job listing that exists but isn't actively hiring. The company posted it months ago, probably isn't reviewing applications, and might not even have a live opening. Estimates put ghost job listings at anywhere from 20% to 40% of what you see on LinkedIn and Indeed on any given day.

The problem is that they look identical to real listings. You can't tell from the title, the company name, or the description. You only figure it out after sending a tailored resume into a void.

I built GhostJob to surface the signal that's already in the listing — you just have to look.

What actually signals a ghost job

Before writing a single line of detection logic, I spent time thinking about what distinguishes a ghost job from a real one given only the information visible on the listing card.

Three signals turned out to be the most reliable:

1. Posting age. This is the strongest signal. A job posted 90+ days ago that hasn't been taken down is almost certainly either abandoned or evergreen (always hiring, always up). Both are forms of ghost job from the applicant's perspective. Real, time-sensitive openings get filled or closed.

2. Description vagueness. Ghost jobs are often templated or copied from old postings. They tend to be short, generic, and missing specific technical requirements. "Strong communication skills and attention to detail" isn't describing a real open role — it's describing every job posting from 2012.

3. Duplicate postings. Some companies maintain permanent listings for roles they hire for occasionally or not at all. If a company has five "Senior Product Manager" postings across different locations that all use identical copy, none of them may be real.

The scoring model

I implemented a simple additive score from 0 to 100:

function daysScore(daysSincePosted: number): number {
  if (daysSincePosted >= 90) return 60;
  if (daysSincePosted >= 60) return 40;
  if (daysSincePosted >= 30) return 20;
  if (daysSincePosted >= 14) return 10;
  return 0;
}

function vaguenessScore(descriptionLength: number, hasSpecificRequirements: boolean): number {
  let score = 0;
  if (descriptionLength < 200) score += 15;
  else if (descriptionLength < 400) score += 8;
  if (!hasSpecificRequirements) score += 10;
  return score;
}

"Specific requirements" means the description mentions a concrete technology, skill level, or credential — React, Python, "3+ years of experience", a certification. Generic descriptions add points; specific ones don't.

The output maps to three tiers: 0–30 is Likely Real, 31–60 is Caution, 61+ is Likely Ghost. I deliberately avoid calling anything definitively a ghost job — the user is making the final call, and false positives have a real cost.

Parsing dates from three different sites

LinkedIn, Indeed, and Glassdoor each have their own date formats and DOM structures. The content script handles each site separately, but they all route through the same date parser:

export function parseDaysAgo(dateText: string): number {
  const text = dateText.toLowerCase().trim();
  if (/today|just posted|now/.test(text)) return 0;
  const dayMatch = text.match(/(\d+)\s*day/);
  if (dayMatch) return parseInt(dayMatch[1], 10);
  const weekMatch = text.match(/(\d+)\s*week/);
  if (weekMatch) return parseInt(weekMatch[1], 10) * 7;
  const monthMatch = text.match(/(\d+)\s*month/);
  if (monthMatch) return parseInt(monthMatch[1], 10) * 30;
  if (/30\+/.test(text)) return 35;
  return 0;
}

Indeed shows "30+ days ago" — a deliberately vague label that hides just how old a listing is. The 30+ match handles that case specifically, mapping it to 35 days.

The SPA problem

LinkedIn and Indeed are single-page applications. They load job cards dynamically as you scroll or filter results. A content script that only runs on document.ready would miss everything loaded after the initial render.

The fix is a MutationObserver that re-runs the scan whenever the DOM changes:

activeObserver = new MutationObserver(() => {
  scanAndInject();
});
activeObserver.observe(document.body, { childList: true, subtree: true });

// Clean up on SPA navigation
window.addEventListener('pagehide', () => activeObserver?.disconnect(), { once: true });

A processing flag prevents concurrent scans from piling up. Each scored card gets data-ghostjob-scored="true" so re-scans skip already-processed cards efficiently.

Injecting badges without breaking the page

The score badge injects as a plain div using insertAdjacentElement('afterend', target) right after the job title. Inline styles instead of injected CSS to avoid specificity battles with each site's stylesheet:

badge.style.cssText = `
  display: inline-flex; align-items: center; gap: 5px;
  padding: 3px 8px; border-radius: 4px;
  background: ${bg}; border: 1px solid ${color}40;
  font-size: 11px; font-weight: 600; color: ${color};
`;
badge.innerHTML = `👻 <span>${label}</span><span style="opacity:0.6"> · ${score}</span>`;
badge.title = `GhostJob Score: ${score}/100`;

The three-tier color system (green/amber/red) makes the signal legible at a glance without requiring the user to read a number.

What the extension is

GhostJob adds a score badge to every job listing on LinkedIn, Indeed, and Glassdoor. Free plan: 20 checks per day. Pro removes the limit and adds a history view.

Available on the Chrome Web Store: https://chromewebstore.google.com/detail/mdjchaohgneaiflafheajamfomeccach

If you're actively job searching, install it and tell me which signals you think are missing from the scoring model — the current weights are a starting point, not a final answer.

More Chrome extension builds at dev-tools-hub.xyz.

How to Avoid Chrome Web Store 'Red Nickel' Rejection: What I Found After Auditing 18 Extensions

SHOTA — Tue, 19 May 2026 16:50:36 +0000

I got my Chrome extension rejected from the Chrome Web Store last week for a 4-letter word: "Free."

Not a permission issue. Not a CSP violation. Not a manifest field. Just the word "Free" sitting in a small badge on my listing image. The Chrome Web Store calls this a Red Nickel violation — their internal name for prohibited promotional language in extension listings.

I run 18 extensions on the store. After the rejection I ran an audit across all of them. 9 had image violations. 14 had description copy violations. Combined, about 80% of my listings tripped at least one Red Nickel rule.

Here's the audit framework I built so this doesn't happen again, plus the categorization that came out of running it.

What "Red Nickel" Actually Is

The public policy text from the Chrome Web Store Developer Program is short:

Listings must not include promotional language or claims about your product, including but not limited to discount notifications, "free" promotions, ratings, awards, or rankings.

Words like "Free", "Best", "Top", "#1", "Award-winning" — even if they're factually true — are not allowed in listing copy, titles, or screenshot images.

"Red Nickel" itself appears to be the internal flag name reviewers use. It isn't in the public documentation. Most developers first hear about it when their extension gets rejected, which is exactly how I learned.

The Two-Hour Audit

After the rejection I wanted to find every remaining violation before the next CWS submission deadline. The audit ran in two passes.

Pass 1 — Image scanning (grep over HTML sources)

All my listing assets are rendered from HTML templates (store-screenshots/html/*.html) before being converted to PNG. That made it easy to grep:

grep -rniE '\b(free|best|top[ -]?rated|#\s*1|無料|最高)\b' \
  extensions/*/store-screenshots/html/

This caught 9 hits across small tiles (440×280) and marquee images (1400×560).

Pass 2 — Description copy (CWS Webstore API)

Listing descriptions live on CWS, not in my repo, so I pulled them via the Chrome Web Store Webstore API for each item and ran the same regex.

14 hits, most of them a trailing "Free." or "Free forever." at the end of feature lists. Easy to miss when you write 18 of them at the same time.

The Four Categories That Came Out of It

The hits clustered into four patterns. I'll walk through them in order of rejection risk.

1. Image badges (highest risk)

This is what got me rejected.

<!-- The line that triggered the rejection -->
<span class="chip">Free</span>

<!-- What I replaced it with -->
<span class="chip">Instant preview</span>

Image text seems to be what reviewers (or automated scanners) check most aggressively. Promotional adjectives here are essentially auto-flagged. Replace them with a functional descriptor that says what the extension does, not how much it costs.

2. Description tail (the "Free." kiss of death)

NG: "Get SEO scores, find issues & export reports. Free forever."
OK: "Get SEO scores, find issues & export reports. Unlimited scans."

Lower review priority than images and currently still passing in many cases, but the policy is the policy. Fix on the next publish cycle so you don't get caught when CWS tightens enforcement.

3. UI mockup labels (gray zone)

If your screenshot mocks a real product UI (Google Flights, Gmail, etc.) and that UI happens to use the word "Best", you're playing a 60/40 game on whether the reviewer reads the context.

<!-- Gray — the original Google Flights label -->
<div class="header">Best departing flights · JPN passport</div>

<!-- Safe side -->
<div class="header">Departing flights · JPN passport</div>

I went with the safe side everywhere. The fix takes 5 minutes; a surprise rejection costs 3-5 days of resubmission. Asymmetric trade — always take the cheap side.

4. Pricing tier names (these are OK)

<div class="plan-name">Free</div>
<div class="plan-price">$0</div>

A pricing table where "Free" sits next to "$0" reads as a tier name, not a promotional claim. Freemium is explicitly allowed by CWS, and the convention is industry standard (Notion, Linear, dozens more). I left these alone, and they've continued to pass review.

The Semantic Edge Case

One pattern I found that confused me: "distraction-free reading."

ZenRead and a few other reading-mode extensions in my portfolio use this. "Free" here is part of a compound adjective ("distraction-free" = "not interrupted by distractions"), not a price claim.

CWS has been letting these through. The judgment seems to be:

If "free" stands alone next to a product noun, it's promotional → NG
If "free" is the second half of a compound that refers to a function or experience, it's semantic → OK

I kept "distraction-free" intact in 2 listings. No issues so far.

The Replacement Framework

The rule I distilled was simple: replace price-attribute words with function-attribute words.

Promotional (NG)	Functional (OK)
Free / Free Forever	"No account" / "Instant" / "Local only"
Free to try / Free to use	"Start immediately" / "No sign-up"
Free Chrome Extension	"MV3 Chrome Extension"
Best / Top-rated	"Complete" / "Built-in" / drop entirely

Functional descriptors are what CWS actively wants in listings. They're more specific (better for the user), they're more honest (better for trust), and they sidestep Red Nickel entirely. A genuine win/win.

The Pre-Publish Gate

After the audit I built a small gate into my publishing workflow:

const RED_NICKEL_PATTERNS: RegExp[] = [
  /\bfree\b/i,
  /\bbest\b/i,
  /\btop[\s-]?rated\b/i,
  /#\s*1\b/,
  /\b無料\b/,
  /\b最高\b/,
];

const SEMANTIC_ALLOWLIST = [
  /distraction-free/i,
  /hands-free/i,
  /lag-free/i,
];

export function scanRedNickel(text: string): RegExp[] {
  if (SEMANTIC_ALLOWLIST.some((p) => p.test(text))) return [];
  return RED_NICKEL_PATTERNS.filter((p) => p.test(text));
}

Before every CWS submission I run this over:

the listing description
the listing title
alt text on each screenshot
the HTML sources for screenshot templates
locale messages.json files (multi-language listings)

If any pattern hits, and the context isn't a pricing tier name ($0 adjacent) or a compound adjective, I fix it before the upload. Five minutes of automation that would have saved me a week of submission churn if I'd written it earlier.

What's Your Trigger Word?

Curious what trips up other CWS publishers. What words got your extension flagged? Drop them in the comments — I'll add the ones I haven't seen to the gate above.

I've been documenting the marketing side of running 18 Chrome extensions at dev-tools-hub.xyz. The CWS SEO learnings have shipped more installs than any paid acquisition channel I've tried — and dodging Red Nickel is now lesson #1 in the pre-publish checklist.

Detecting YouTube SPA Navigation in a Chrome Extension Content Script

SHOTA — Thu, 14 May 2026 16:11:12 +0000

YouTube is a single-page application. The page never fully reloads when you click a video. The URL changes, the DOM updates, but DOMContentLoaded fires exactly once — when Chrome first loads the tab.

This breaks the most natural assumption in Chrome extension development: that your content script runs once per page. For YouTube, "once per page load" means once for the entire session.

I hit this while building LectureLoop — an extension that injects a side panel and loop replay controls onto YouTube lecture videos. When a user navigates from one video to another, the extension needs to reset, re-detect the video element, and reinitialize its state. Without handling SPA navigation, it just… stops working after the first video.

The Problem with `window.location`

The naive fix is to watch window.location.href for changes. Chrome content scripts can read window.location freely. The issue is timing: YouTube uses the History API (history.pushState) to update the URL. There's no event you can listen to directly — popstate only fires on back/forward navigation, not on pushState calls.

You could poll with setInterval, but polling is inaccurate by definition and wastes CPU even when nothing is happening.

MutationObserver on `document.body`

The approach that actually works is watching document.body for DOM subtree changes and comparing the URL on each mutation:

let lastUrl = location.href;

const navObserver = new MutationObserver(() => {
  if (location.href !== lastUrl) {
    lastUrl = location.href;
    setTimeout(init, 1500);
  }
});

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

window.addEventListener('pagehide', () => navObserver.disconnect(), { once: true });

The setTimeout(init, 1500) gives YouTube's React app time to finish rendering the new video element before init() tries to query it. Without the delay, document.querySelector('video') returns null — YouTube has updated the URL but hasn't yet replaced the DOM.

The pagehide cleanup matters: if the tab is closed or navigated away from, you want to disconnect the observer rather than leaving it running against an unmounted document.

The Loop Replay Implementation

Once the content script reliably re-runs on navigation, implementing loop replay is straightforward. The side panel sends a message to the content script to jump to a specific timestamp:

chrome.runtime.onMessage.addListener((msg) => {
  if (msg.type === 'JUMP_TO_TIMESTAMP' && typeof msg.sec === 'number') {
    const video = document.querySelector('video');
    if (video) video.currentTime = msg.sec;
  }
});

The side panel tracks the loop start and end points. When the video's timeupdate event fires and the current time exceeds the loop end, it sends JUMP_TO_TIMESTAMP with the loop start time. This gives users a way to replay a specific section of a lecture repeatedly without scrubbing the timeline by hand.

Why Not `scripting.executeScript`?

An alternative is to use chrome.scripting.executeScript from the background service worker instead of keeping long-lived listeners in a content script. The tradeoff: executeScript requires the scripting permission, which triggers a warning in the Chrome Web Store review process about "reading browsing history." Using a content script with matches: ["https://www.youtube.com/*"] avoids this — it's a declared, static permission that reviewers understand at a glance.

It's a minor point, but CWS reviewers look at permissions carefully. Keeping the injection in the content script declaration rather than calling executeScript from background kept the permission list clean.

Lessons

Three things I'd do differently on the next extension that needs SPA navigation handling:

Set the URL guard at the start of init(), not just in the observer. If init() is async and runs while the user clicks to a third video, you can end up with two concurrent initializations racing each other.
Use a cancellation token. Start each init() with an incrementing ID, and bail out of the async steps if a newer ID has been issued.
Log every navigation event in development. YouTube's SPA navigation is fast and the delay is imprecise — having a visible indicator that the observer fired makes the timing problem much easier to debug.

🔗 LectureLoop on Chrome Web Store: Install

I Built a Price History Tracker for Japan's 4 Major E-Commerce Sites (Amazon.co.jp, Rakuten, Yahoo!, Mercari)

SHOTA — Tue, 12 May 2026 16:20:43 +0000

Keepa tracks Amazon price history. It works well for Amazon.com. For Amazon.co.jp it has gaps — delayed updates, missing products, no Rakuten/Yahoo!/Mercari support at all.

If you shop regularly on Japanese e-commerce, you're working across four very different sites with no unified price history. I wanted to know: was this ¥9,800 laptop stand expensive last month, or is it always ¥9,800? Is this Mercari listing a fair price compared to last week?

I built PricePulse JP to answer that. The interesting engineering problem was getting consistent price data out of four sites that don't look anything alike.

The four-site parsing problem

The naive approach to price extraction is: find the DOM element that shows the price, read textContent. That works until Amazon quietly renames its CSS classes (which it does, routinely), or you're on a Rakuten shop that a merchant themed themselves.

Each site needed a different strategy.

Amazon.co.jp mutates its DOM frequently enough that a single selector is a liability. I maintain a fallback chain of 8 selectors in priority order:

const priceSelectors = [
  '#corePriceDisplay_desktop_feature_div .a-price .a-offscreen',
  '#corePrice_feature_div .a-price .a-offscreen',
  '#apex_desktop .a-price .a-offscreen',
  '#priceblock_ourprice',
  '#priceblock_dealprice',
  '#priceblock_saleprice',
  'span.a-price.apexPriceToPay .a-offscreen',
  '.a-price .a-offscreen',  // last resort
];

The first selector that returns a non-zero price wins. This survives most Amazon layout changes because at least one selector in the chain is usually current.

Rakuten is harder. Rakuten Ichiba lets merchants customize shop layouts, so DOM selectors vary wildly across shops. The saving grace: Rakuten enforces schema.org Product metadata platform-wide. Every item page has <meta itemprop="price" content="...">. Merchant themes can't change that. I parse metadata first and only fall back to DOM selectors if the metadata is absent.

Yahoo! Shopping has two URL patterns (store.shopping.yahoo.co.jp and shopping.yahoo.co.jp/products/) and also reliably exposes schema.org meta[itemprop="price"]. Same approach as Rakuten: metadata first.

Mercari also uses schema.org metadata — meta[itemprop="price"] and meta[property="product:price:amount"]. The Mercari-specific edge case is that sold items don't have a price. When an item sells, the price meta disappears. The parser returns null in this case instead of writing a zero, which preserves the last known price in the watchlist rather than recording a false "price dropped to 0."

Why one parser runs in two contexts

There's a common architecture question with Chrome extensions: do you parse in the content script (runs in the page's tab) or in the background service worker (runs separately)?

Content scripts have direct DOM access. Service workers can use fetch() and DOMParser but don't have live DOM. For price tracking you want both: parse on page load (for immediate feedback) and re-check in the background on a schedule (for alerts when you're not browsing).

The solution is to write each parser as a pure function that takes a Document argument:

export function parseAmazonDoc(doc: Document, sourceUrl: string): ParsedProduct | null

The content script passes document. The background refresh task passes the result of:

const res = await fetch(url, { headers: { 'Accept': 'text/html' } });
const html = await res.text();
const doc = new DOMParser().parseFromString(html, 'text/html');

Same logic, two inputs. No code duplication.

Storing price history without external dependencies

Price history needs a proper database — not chrome.storage.local (5 MB quota, slow on large reads) and not a remote server (I wanted this fully local).

IndexedDB fits. Two object stores:

watchlist: keyed by product ID, indexed by site. Stores the product title, URL, current price.
history: compound key [watchId, timestamp], append-only. Each price check writes a new point.

const DB_NAME = 'pricepulse';

// watchlist: { id, site, title, url, currentPrice, addedAt }
const watchlistStore = db.createObjectStore('watchlist', { keyPath: 'id' });
watchlistStore.createIndex('site', 'site', { unique: false });

// history: append-only price log per product
db.createObjectStore('history', { keyPath: ['watchId', 't'] });

I wrote this without the idb wrapper library to keep bundle size small. The raw IndexedDB API is verbose but the transaction pattern is manageable once you wrap it:

function tx<T>(store: string, mode: IDBTransactionMode, run: (tx: IDBTransaction) => T): Promise<T>

Price drop alerts

The background check runs on a chrome.alarms schedule. Alarms fire even when no tab is open. When the fetched price is lower than the stored targetPrice threshold, it triggers a desktop notification:

chrome.alarms.create('priceCheck', { periodInMinutes: 60 });

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name !== 'priceCheck') return;
  const watchlist = await db.getAllWatching();
  for (const item of watchlist) {
    const updated = await fetchPriceForWatch(item);
    if (updated && item.targetPrice && updated.price <= item.targetPrice) {
      chrome.notifications.create({ /* ... price drop alert ... */ });
    }
  }
});

What it is

PricePulse JP tracks prices across Amazon.co.jp, Rakuten, Yahoo! Shopping, and Mercari. Add items to your watchlist, set a target price, and get a notification when they drop. Price history chart is visible in the popup. Free plan: 10 items. Pro removes the limit and adds CSV export.

Available on the Chrome Web Store: [PricePulse JP — coming soon]

Part of my series on building Chrome extensions for the Japanese market. More at dev-tools-hub.xyz.

I Built a Chrome Extension That Catches Japanese Ad Law Violations in Real Time

SHOTA — Sun, 10 May 2026 14:52:48 +0000

Japanese advertising law is a minefield.

If you work in Japanese digital marketing, you know the anxiety. A single word like 最高 (best) or 必ず (guaranteed) could technically violate 景品表示法 (Keihyo-ho). A beauty product description mentioning skin improvement might run afoul of 薬機法 (Yakki-ho). An influencer post without a clear "PR" disclosure triggers ステルスマーケティング (stealth marketing) regulations.

I was helping a friend review ad copy for a cosmetics brand when I realized: there is no tooling for this. No browser extension, no real-time checker, nothing. You either know the rules by heart or you pay a lawyer.

So I built one.

What AdLegalCheck Does

AdLegalCheck is a Chrome extension that automatically scans any webpage you visit and flags potential violations across three Japanese legal frameworks:

景品表示法 (Keihyo-ho) — Misleading claims, exaggerated benefits, prohibited comparative advertising
薬機法 (Yakki-ho) — Health and beauty claims that are illegal for cosmetics and quasi-drugs
ステルスマーケティング規制 — Undisclosed sponsored content or paid reviews

When you open a product page or ad landing page, the extension:

Scans the visible text for 68 high-risk keywords and patterns
Highlights risky words directly on the page
Opens a side panel with a risk score (0-100) and findings sorted by severity
(Pro) Runs GPT-4o-mini AI analysis for context-aware evaluation

The Technical Stack

Built with WXT + React + TypeScript — WXT gives you a proper build system with HMR, TypeScript out of the box, and sensible MV3 defaults.

adlegalcheck/
├── entrypoints/
│   ├── content.ts        # Page scanner + keyword highlighter
│   ├── sidepanel/        # React UI for results
│   └── background.ts     # Message bus + usage tracking
├── lib/
│   ├── keywords.ts       # 68 NG keyword database
│   ├── scanner.ts        # Regex matching engine
│   └── ai-analyzer.ts    # GPT proxy client
└── wxt.config.ts

The Keyword Database

The core is a curated list of 68 expressions organized by violation type and severity:

type KeywordEntry = {
  pattern: RegExp;
  law: "keihyo" | "yakki" | "stealth";
  severity: "high" | "medium" | "low";
  reason: string;
};

const keywords: KeywordEntry[] = [
  {
    pattern: /日本一|No\.?\s*1|ナンバーワン/g,
    law: "keihyo",
    severity: "high",
    reason: "Absolute superiority claims require substantiation",
  },
  {
    pattern: /必ず|絶対に|100%/g,
    law: "keihyo",
    severity: "high",
    reason: "Guarantee expressions violate 景表法 §5",
  },
  {
    pattern: /美白|シミが消|肌が若返/g,
    law: "yakki",
    severity: "high",
    reason: "Prohibited efficacy claims for cosmetics",
  },
];

Content Script: Highlighting Without Breaking the Page

The trickiest part was highlighting keywords inside arbitrary DOM trees without corrupting the page structure. I use a TreeWalker to find text nodes, then wrap matches in <mark> elements:

function highlightInNode(node: Text, matches: Match[]): void {
  const text = node.textContent ?? "";
  if (matches.length === 0) return;

  const fragment = document.createDocumentFragment();
  let lastIndex = 0;

  for (const match of matches) {
    if (match.start > lastIndex) {
      fragment.appendChild(
        document.createTextNode(text.slice(lastIndex, match.start))
      );
    }
    const mark = document.createElement("mark");
    mark.className = `adlc-highlight adlc-${match.severity}`;
    mark.textContent = text.slice(match.start, match.end);
    mark.title = match.reason;
    fragment.appendChild(mark);
    lastIndex = match.end;
  }

  if (lastIndex < text.length) {
    fragment.appendChild(document.createTextNode(text.slice(lastIndex)));
  }

  node.parentNode?.replaceChild(fragment, node);
}

AI Analysis via Vercel Proxy

The Pro feature sends the page text to GPT-4o-mini for context-aware analysis. A keyword matcher cannot understand nuance — "最高の気分" (feeling great) is fine; "最高の効果" (highest efficacy) is not.

I route all AI calls through a Vercel serverless function so the OpenAI API key never touches the client:

const response = await fetch(
  "https://s-hub-dashboard.vercel.app/api/llm/chat",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      messages: [
        {
          role: "system",
          content: `You are a Japanese advertising law compliance expert.
            Analyze the provided text for violations of:
            1. 景品表示法 (misleading claims, absolute superiority)
            2. 薬機法 (prohibited health/beauty efficacy claims)
            3. ステルスマーケティング規制 (undisclosed sponsorship)
            Return JSON: { riskScore: 0-100, findings: Finding[], summary: string }`,
        },
        { role: "user", content: pageText.slice(0, 4000) },
      ],
    }),
  }
);

Risk Score Calculation

The 0-100 risk score combines keyword density and AI analysis:

function calculateRiskScore(
  keywordFindings: Finding[],
  aiScore?: number
): number {
  const keywordScore = Math.min(
    keywordFindings.reduce((acc, f) => {
      const weights = { high: 20, medium: 10, low: 5 };
      return acc + weights[f.severity];
    }, 0),
    70
  );

  if (aiScore !== undefined) {
    return Math.round(keywordScore * 0.4 + aiScore * 0.6);
  }
  return keywordScore;
}

Freemium Design

Free tier: 3 page scans per month, keyword matching only.
Pro ($9.99/month): Unlimited scans + AI analysis + CSV export.

Monetization via ExtensionPay — no backend needed for payments.

Who Is This For?

Japanese marketing teams and copywriters who need a quick gut-check before publishing:

Draft ad copy, put it on a staging page
Open the extension, hit scan
Red highlights = fix before legal review
Ship with confidence

Not a replacement for a lawyer — the disclaimer is built into the UI. But catching obvious violations before they reach legal review saves time and money.

What is Next

Better pattern matching for idiomatic expressions
Support for 特定商取引法 (e-commerce disclosure requirements)
Batch scanning via CSV upload (Pro roadmap)

The extension is live on the Chrome Web Store.

Built with WXT + React + TypeScript. AI analysis powered by GPT-4o-mini via Vercel serverless.

DEV Community: SHOTA

I Built a Visa Requirement Overlay for Google Flights — Here's How the Chrome Extension Works

The Core Idea

Local JSON Matrix, Zero API Calls

The Hard Part: Google Flights Is a SPA

Extracting Destination Text From an Obfuscated DOM

Country Name → ISO Code

Cleanup

Building a Japanese-First Subscription Tracker PWA (Next.js 15 + Supabase + Serwist)

The stack

Part 1: "member slots" and enforcing a freemium quota in the database

Part 2: payment-method-aware cancel links

Part 3: Web Push on iOS without losing your mind

What I'd tell past me

Auto-Replay Lecture Segments in Your Browser — Building a Chrome Extension for Focused Learning

Getting timestamps out of YouTube

Jumping to a timestamp: the cross-context messaging problem

Tracking navigation on a SPA

Why chrome.sidePanel instead of a popup

What the extension does

Building a Japanese-First Read-Later PWA: From Pocket Shutdown to Launch

The stack

Three things that bit me

1. Article extraction on Vercel serverless

2. Storing article body on-device

3. i18n routing — the silent sitemap killer

Where Readbox is now

ReadBox — Read-it-later PWA for Pocket refugees

I Applied SLA Concepts to My Email Inbox — Here's What I Learned Building the Chrome Extension

The Core Idea

The Hard Part: Gmail Is a SPA

Extracting Email Metadata From an Obfuscated DOM

Badge Injection Without Breaking Gmail

MV3: Content Script ↔ Background Service Worker

What I'd Do Differently

190 Countries, Zero API Calls: Shipping Static Data in a Chrome Extension

Why Static Over API

Data Structure

Bundling with WXT

Content Script Injection on Google Flights

The Maintenance Problem

How to detect ghost jobs in 2026 — a developer's guide

The numbers (so you know this isn't rare)

What "ghost job" actually means

The four signals I use

Signal 1: Posting age

Signal 2: Repost frequency (Levenshtein distance)

Signal 3: Hidden salary in disclosure-mandatory states

Signal 4: Company-level repost rate

Putting it together

Architecture: MV3, no servers

What I'd do differently

The product

Question for you

Ghost Jobs Are Wasting Your Time — I Built a Chrome Extension to Detect Them

What actually signals a ghost job

The scoring model

Parsing dates from three different sites

The SPA problem

Injecting badges without breaking the page

What the extension is

How to Avoid Chrome Web Store 'Red Nickel' Rejection: What I Found After Auditing 18 Extensions

What "Red Nickel" Actually Is

The Two-Hour Audit

Pass 1 — Image scanning (grep over HTML sources)

Pass 2 — Description copy (CWS Webstore API)

The Four Categories That Came Out of It

1. Image badges (highest risk)

2. Description tail (the "Free." kiss of death)

3. UI mockup labels (gray zone)

4. Pricing tier names (these are OK)

The Semantic Edge Case

The Replacement Framework

The Pre-Publish Gate

What's Your Trigger Word?

Detecting YouTube SPA Navigation in a Chrome Extension Content Script

The Problem with window.location

MutationObserver on document.body

The Loop Replay Implementation

Why Not scripting.executeScript?

The Problem with `window.location`

MutationObserver on `document.body`

Why Not `scripting.executeScript`?