AVOID — Stale and unlicensed — last commit 3y ago

• 3 active contributors
• ⚠ Stale — last commit 3y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 67% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ No test directory detected
• ⚠ Scorecard: marked unmaintained (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests + OpenSSF Scorecard}

A comprehensive Chrome Extension (not plugin, technically) education repository demonstrating end-to-end extension development with three production-ready demos: full-chrome-plugin-demo (21KB JavaScript with manifest.json, background scripts, content scripts, devtools integration, options pages), simple-chrome-plugin-demo (minimal starter template), and page-action-demo (illustrating page-action vs browser-action). Solves the problem of learning Chrome Extension APIs through working, runnable code paired with a complete Chinese-language tutorial. Three parallel demo directories at root level: full-chrome-plugin-demo/ (main teaching demo with manifest.json, background.html, popup.html, mypanel.html, newtab.html, options.html, devtools.html, plus js/ subdirectory with background.js, content-script.js, popup.js, devtools.js, inject.js, mypanel.js), simple-chrome-plugin-demo/ (3 files only: manifest.json, popup.js, popup.html), and page-action-demo/ (separate to avoid manifest conflicts). _locales/zh_CN and en/ contain i18n strings for both languages.

Chinese-speaking web developers and students learning Chrome Extension development who want copy-paste demos and concrete examples. Specifically targets beginners who need to understand manifest.json, content-script-to-background communication, devtools panels, popup interactions, and cross-realm messaging—not abstract documentation.

Educational/reference-grade, not production library code. The repo is 5+ years old (referenced blog post from 2017) with stable snapshot demos. No CI/CD, no test suite, no version bumps expected—it's a tutorial codebase frozen as a working reference. Actively used as study material but not maintained for new Chrome API versions.

No NPM dependencies (uses inline jQuery 1.8.3 from 2012). Single-author, no issue tracker visible. Critical risk: Chrome manifest_version 2 is deprecated since 2021 and removed in Chromium 88+; all demos require migration to manifest_version 3 for current Chrome versions. manifest.json snippets show MV2 syntax (background.page, no service workers). No updates visible for MV3 compatibility.

Repository appears dormant—last activity inferred to be 2017. No active development, no open issues/PRs visible in metadata. Serves as frozen educational snapshot. No roadmap for MV3 migration or new Chrome API integration.

git clone https://github.com/sxei/chrome-plugin-demo.git
cd chrome-plugin-demo
# Open chrome://extensions in Chrome, enable 'Developer mode' (top-right toggle)
# Click 'Load unpacked', select 'full-chrome-plugin-demo' or 'simple-chrome-plugin-demo'
# No npm install, no build step—manifests are loadable as-is (MV2 syntax requires legacy Chrome)

Daily commands: No build step. For MV2 (legacy Chrome <88): chrome://extensions → Load unpacked → select folder. For current Chrome (MV3 required): fork/migrate manifest.json to v3, replace background.page with background.service_worker, rewrite scripts. Demos include no local server; everything runs in extension sandbox.

• full-chrome-plugin-demo/manifest.json: Declares all plugin metadata, permissions, background page, browser_action, content scripts, and i18n resources—required for Chrome to recognize and load the extension.
• full-chrome-plugin-demo/js/background.js: Persistent background script handling extension lifecycle events, tab listeners, and inter-script messaging hub (chrome.runtime.onMessage)—the 'server' of the extension.
• full-chrome-plugin-demo/js/content-script.js: Injected into all matching pages, accesses page DOM and passes data back to background.js via chrome.runtime.sendMessage—bridge between page context and extension context.
• full-chrome-plugin-demo/popup.html: Browser-action popup UI; demonstrates chrome.tabs API calls and message-passing from popup to background.
• full-chrome-plugin-demo/js/devtools.js: DevTools panel script; shows how to integrate inspection tools as custom panels using chrome.devtools API.
• simple-chrome-plugin-demo/manifest.json: Minimal MV2 template (3-file extension) for rapid prototyping; reference for the absolute minimum required structure.
• full-chrome-plugin-demo/_locales/zh_CN/messages.json: i18n strings for Chinese; demonstrates Chrome's localization system via MSG_xxx placeholders in HTML.

Start by editing files in order of isolation: 1) full-chrome-plugin-demo/popup.html + popup.js for popup UI changes (safest, immediate). 2) full-chrome-plugin-demo/manifest.json to add permissions, new page actions, content script patterns. 3) full-chrome-plugin-demo/js/background.js for event handling and inter-script communication (uses chrome.runtime.sendMessage). 4) full-chrome-plugin-demo/js/content-script.js to modify page inspection logic. 5) full-chrome-plugin-demo/mypanel.html + js/mypanel.js to add devtools panel features. Always reload (Ctrl+R on extensions page) after changes.

CRITICAL: Manifest v2 is obsolete. All demos use MV2 syntax (background.page, scripts array under background). Modern Chrome (≥88) rejects MV2 extensions entirely. To run locally, either use ancient Chrome/Chromium or migrate manifests to v3 (background.service_worker, async messaging). No warning in README. | jQuery 1.8.3 is 12+ years old (security, compatibility). | Content-script injection pattern in manifest.json uses glob patterns (e.g., http://) which may not match HTTPS-only modern sites without explicit https:// pattern. | popup.html and options.html rely on inline styles/scripts, which would violate MV3 CSP; separate .css and .js files required for v3. | No error handling in message-passing; failed chrome.runtime.sendMessage calls silently fail without try-catch. | DevTools panel (mypanel.html) only works when DevTools window is open; state not persisted if DevTools closes.

• Content Script vs. Injected Script — Chrome extensions run in an isolated context; content-scripts have partial DOM access but no page JS access, while inject.js runs in page context—this repo shows both patterns and why the distinction matters for security and functionality.
• Chrome Message Passing (chrome.runtime.sendMessage) — Extensions are multi-process (popup, background, content-script run in separate realms); this repo demonstrates the primary IPC mechanism for cross-script communication via callback or Promise.
• Manifest v2 vs. v3 (Extension Lifecycle Change) — This repo freezes MV2 (persistent background page, callback-based messaging); Chrome removed MV2 in 2024, forcing all extensions to MV3 (service workers, async messaging, event-driven)—major architectural shift every learner must eventually understand.
• DevTools API (chrome.devtools.panels) — This repo shows how to extend browser DevTools with custom panels; full-chrome-plugin-demo/js/devtools.js + mypanel.html demonstrate integrating inspection logic into the browser's native debugging UI.
• i18n with chrome.i18n (Localization) — Extension UI is localized via _locales/ directories and MSG_keyName placeholders; this repo demonstrates the standard Chrome approach for multi-language extensions.
• Security Origin & Sandbox Isolation — Content scripts run in a modified page context (can access DOM but not page JS), background scripts run in extension context (no DOM access). This security model is the reason message-passing is necessary and why injection.js exists in this repo.
• Browser Action vs. Page Action (MV2 terminology) — This repo includes both: browser_action (always visible popup icon) in full-chrome-plugin-demo and page_action (conditional icon) in page-action-demo. MV3 unified this into action; understanding the difference clarifies intent-driven UI design.

• GoogleChrome/chrome-extensions-samples — Official Chrome team's maintained example extensions covering MV3 API patterns, devtools, content scripts, and service workers—canonical reference after this educational snapshot becomes outdated.
• mozilla/webextensions-examples — Firefox WebExtensions API (API-compatible with Chrome's for most features); shows cross-browser extension patterns that work in both Chrome and Firefox.
• electron/electron — Alternative to Chrome extensions for desktop app development; many learners graduating from this repo explore Electron for similar 'customize the browser experience' goals.
• webpack/webpack — Modern extension development uses bundlers; learners migrating full-chrome-plugin-demo to MV3 will need webpack or esbuild for splitting background.service_worker and content-scripts into separate bundles.
• tc39/ecma262 — Extension development uses ES5 (jQuery era) in this repo; understanding Promise/async-await (ES6+) is critical for MV3 migration and modern patterns.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create comprehensive manifest.json validation guide and example comparisons

The repo contains three separate demo projects (full-chrome-plugin-demo, simple-chrome-plugin-demo, page-action-demo) each with different manifest.json configurations. A new contributor could create a detailed markdown document explaining the differences between these manifests (especially between Manifest V2 in full-demo vs potential V3 updates), including a side-by-side comparison table. This would help users understand which configuration to use for their use case.

• [ ] Compare manifest.json files across all three demo directories
• [ ] Document differences in permissions, background scripts, page_actions, and content_scripts declarations
• [ ] Create MANIFEST_GUIDE.md with side-by-side examples and when to use each approach
• [ ] Add comments to each manifest.json explaining non-obvious fields

Add build script and package.json for demo project distribution

Currently, the repo lacks a package.json and build automation. Adding npm scripts to bundle, minify, and package each demo as a .crx file or distribution-ready folder would make the repo immediately usable. This is especially valuable since the README mentions 'clone and run' but provides no build instructions.

• [ ] Create package.json in root with scripts for building each demo independently
• [ ] Add a build script that minifies JS/CSS in full-chrome-plugin-demo/js and css directories
• [ ] Create a dist/ output structure for each demo ready for chrome://extensions/ loading
• [ ] Document in README.md how to run npm run build and load demos locally

Create localization testing utility and expand message keys across all demos

The repo has _locales directories with en and zh_CN translations in full-chrome-plugin-demo, but these are incomplete (only messages.json files exist) and other demos don't use localization at all. A contributor could create a validation script to ensure all i18n message keys are complete, add missing translations, and extend localization to simple-chrome-plugin-demo and page-action-demo.

• [ ] Audit existing messages.json files in _locales/en and _locales/zh_CN for completeness
• [ ] Create a Node.js validation script (scripts/validate-locales.js) that checks all keys in en/ exist in zh_CN/
• [ ] Add missing UI strings (popup.html, options.html, devtools.html) to both locale files
• [ ] Add _locales directories with basic translations to simple-chrome-plugin-demo and page-action-demo

• Migrate full-chrome-plugin-demo to Manifest v3: Replace background.page with background.service_worker in manifest.json, convert all inline event listeners to top-level promises, rewrite chrome.runtime.sendMessage calls to handle Promise-based responses instead of callbacks. Estimated impact: all three demos work on current Chrome.
• Add unit tests for content-script.js: Create a test directory with Jest setup testing the DOM selectors and message-passing logic in js/content-script.js and js/show-image-content-size.js. Currently zero test coverage; this catches breakage from future maintainers.
• Document MV2→MV3 migration guide in README: Add a 'Upgrading from MV2' section with before/after code snippets for the three key changes (background page → service worker, callback → Promise messaging, inline styles → external CSS). Prevents learners from copy-pasting broken code.

• High · Outdated jQuery Library — full-chrome-plugin-demo/js/jquery-1.8.3.js. The codebase includes jquery-1.8.3.js, which was released in 2012 and contains multiple known security vulnerabilities including XSS and prototype pollution issues. This is an extremely outdated version with no security patches. Fix: Update to the latest stable version of jQuery (3.6.x or later). Review all jQuery usage and replace with modern vanilla JavaScript alternatives where possible, especially for DOM manipulation.
• High · Content Script XSS Risk — full-chrome-plugin-demo/js/content-script.js, full-chrome-plugin-demo/js/inject.js, full-chrome-plugin-demo/js/show-image-content-size.js. Content scripts (content-script.js, inject.js, show-image-content-size.js) interact with page DOM and may be vulnerable to XSS attacks if they process untrusted data from web pages without proper sanitization. The presence of inject.js suggests injected scripts that could execute arbitrary code. Fix: Implement strict input validation and output encoding for all DOM operations. Use textContent instead of innerHTML. Implement a Content Security Policy (CSP) in manifest.json. Avoid using eval() or Function() constructors.
• High · Missing Content Security Policy — full-chrome-plugin-demo/manifest.json, simple-chrome-plugin-demo/manifest.json, page-action-demo/manifest.json. The manifest.json files do not appear to enforce a Content Security Policy (CSP), which is critical for preventing inline script execution and injection attacks in Chrome extensions. Fix: Add a strict CSP to manifest.json: 'content_security_policy': { 'extension_pages': "script-src 'self'; object-src 'self'" }
• Medium · Overly Permissive Manifest Permissions — full-chrome-plugin-demo/manifest.json, simple-chrome-plugin-demo/manifest.json, page-action-demo/manifest.json. Without reviewing the full manifest.json content, typical Chrome extension demos often request excessive permissions (tabs, webRequest, storage, etc.). This violates the principle of least privilege. Fix: Audit all permissions in manifest.json and remove unnecessary ones. Only request permissions that are absolutely required for functionality. Use optional_permissions for non-critical features.
• Medium · Potential Message Injection in Background Scripts — full-chrome-plugin-demo/js/background.js, page-action-demo/js/background.js. Background scripts (background.js) commonly use chrome.runtime.sendMessage and onMessage listeners. Without proper validation of message sources and content, these can be exploited for injection attacks. Fix: Validate all incoming messages. Check sender.url or sender.id to ensure messages come from expected sources. Sanitize and validate all data received through messaging APIs before using it.
• Medium · localStorage Usage Without Encryption — full-chrome-plugin-demo/js/options.js, full-chrome-plugin-demo/js/popup.js. Chrome extension demos typically use localStorage or chrome.storage APIs without encryption. If sensitive data is stored, it could be accessed by malicious scripts or if the extension is compromised. Fix: Avoid storing sensitive data in localStorage. Use chrome.storage.sync with encryption for any sensitive information. Consider using chrome.storage with limited scope.
• Low · Missing Manifest Version Specification — full-chrome-plugin-demo/manifest.json, simple-chrome-plugin-demo/manifest.json, page-action-demo/manifest.json. Modern Chrome extensions should explicitly declare manifest_version 3 (or at minimum 2). Older versions have deprecated security features and lack modern protections. Fix: Update to 'manifest_version': 3 and refactor code accordingly. This enables modern security features including stricter CSP and service worker isolation.
• Low · No HTTPS Enforcement for External Resources — README.md. The README references external image URLs over HTTP (image.liuxianan.com, img.alicdn.com). Extensions should enforce HTTPS for all external resources. Fix: Ensure all external resource URLs use HTTPS. Configure manifest

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/sxei/chrome-plugin-demo shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sxei/chrome-plugin-demo repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sxei/chrome-plugin-demo.

What it runs against: a local clone of sxei/chrome-plugin-demo — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sxei/chrome-plugin-demo | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | Last commit ≤ 1221 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sxei/chrome-plugin-demo. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sxei/chrome-plugin-demo.git
#   cd chrome-plugin-demo
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sxei/chrome-plugin-demo and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sxei/chrome-plugin-demo(\\.git)?\\b" \\
  && ok "origin remote is sxei/chrome-plugin-demo" \\
  || miss "origin remote is not sxei/chrome-plugin-demo (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1221 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1191d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sxei/chrome-plugin-demo"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.