Content Script

You are a browser extension developer. The user wants to create a content script that safely manipulates DOM elements on web pages while respecting isolation boundaries and extension permissions.

What to check first

• Look at manifest.json to verify "permissions" includes "activeTab" and target URL patterns in "content_scripts"
• Verify the "matches" pattern in manifest covers the pages where your script should run (e.g., "https://*.example.com/*")
• Check browser console for CSP (Content Security Policy) violations that may block inline scripts

Steps

1. Add the content script entry to manifest.json under "content_scripts" with "matches", "js", and optional "css" arrays
2. Create a separate .js file for your content script (do not inline in manifest)
3. Use document.addEventListener() to wait for DOM readiness instead of assuming elements exist immediately
4. Select target elements with document.querySelector() or document.querySelectorAll() after DOM is ready
5. Modify elements directly: set .innerHTML, .textContent, .style, or .classList properties
6. Use chrome.runtime.sendMessage() to communicate with the background script if you need access to extension APIs
7. Clean up event listeners and avoid memory leaks by removing listeners when content is no longer needed
8. Test with chrome://extensions/ in developer mode and check the content script console for errors

Code

// content-script.js
// Runs in the context of the web page, with access to the DOM
// BUT cannot access chrome.* APIs directly

(function() {
  'use strict';

  // Wait for DOM to be ready
  function initContentScript() {
    // Example 1: Modify all links to open in a new tab
    const allLinks = document.querySelectorAll('a[href]');
    allLinks.forEach(link => {
      link.setAttribute('target', '_blank');
      link.setAttribute('rel', 'noopener noreferrer');
    });

    // Example 2: Inject a style rule
    const style = document.createElement('style');
    style.textContent = `
      body { background-color: #f0f0f0; }
      a { color: #0066cc; }
    `;
    document.head.appendChild(style);

    // Example 3: Listen for user interaction and send data to background
    document.addEventListener('click', (event) => {
      if (event.target.matches('button.track-me')) {
        chrome.runtime.sendMessage({
          action: 'logClick',
          element: event.target.textContent,
          timestamp: new Date().toISOString()
        }, (response) => {
          console.log('Background response:', response);
        });
      }
    });

    // Example 4: Monitor for dynamically added elements
    const observer = new MutationObserver((mutations) => {

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change