npm - chrome-devtools-mcp - Versions diffs - 1.3.0 → 1.4.0 - Mend

chrome-devtools-mcp 1.3.0 → 1.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (26) hide show

package/README.md +37 -2
package/build/src/bin/check-latest-version.js +1 -0
package/build/src/bin/chrome-devtools-mcp-cli-options.js +2 -2
package/build/src/formatters/NetworkFormatter.js +3 -1
package/build/src/third_party/THIRD_PARTY_NOTICES +3 -3
package/build/src/third_party/bundled-packages.json +3 -3
package/build/src/third_party/devtools-heap-snapshot-worker.js +13 -0
package/build/src/third_party/index.js +1522 -230
package/build/src/utils/check-for-updates.js +1 -0
package/build/src/version.js +1 -1
package/package.json +7 -6
package/skills/a11y-debugging/SKILL.md +89 -0
package/skills/a11y-debugging/references/a11y-snippets.md +92 -0
package/skills/chrome-devtools/SKILL.md +72 -0
package/skills/chrome-devtools-cli/SKILL.md +153 -0
package/skills/chrome-devtools-cli/references/installation.md +14 -0
package/skills/debug-optimize-lcp/SKILL.md +121 -0
package/skills/debug-optimize-lcp/references/elements-and-size.md +27 -0
package/skills/debug-optimize-lcp/references/lcp-breakdown.md +23 -0
package/skills/debug-optimize-lcp/references/lcp-snippets.md +79 -0
package/skills/debug-optimize-lcp/references/optimization-strategies.md +38 -0
package/skills/memory-leak-debugging/SKILL.md +50 -0
package/skills/memory-leak-debugging/references/common-leaks.md +33 -0
package/skills/memory-leak-debugging/references/compare_snapshots.js +109 -0
package/skills/memory-leak-debugging/references/memlab.md +29 -0
package/skills/troubleshooting/SKILL.md +98 -0

package/skills/debug-optimize-lcp/references/lcp-snippets.md ADDED Viewed

@@ -0,0 +1,79 @@
+# LCP Debugging Snippets
+Use these JavaScript snippets with the `evaluate_script` tool to extract deep insights from the page.
+## 1. Identify LCP Element
+Use this snippet to identify the LCP element and get raw timing data from the Performance API.
+```javascript
+async () => {
+  return await new Promise(resolve => {
+    new PerformanceObserver(list => {
+      const entries = list.getEntries();
+      const last = entries[entries.length - 1];
+      resolve({
+        element: last.element?.tagName,
+        id: last.element?.id,
+        className: last.element?.className,
+        url: last.url,
+        startTime: last.startTime,
+        renderTime: last.renderTime,
+        loadTime: last.loadTime,
+        size: last.size,
+      });
+    }).observe({type: 'largest-contentful-paint', buffered: true});
+  });
+};
+```
+## 2. Audit Common Issues
+Use this snippet to check for common DOM-based LCP issues (lazy loading, priority).
+```javascript
+() => {
+  const issues = [];
+  // Check for lazy-loaded images in viewport
+  document.querySelectorAll('img[loading="lazy"]').forEach(img => {
+    const rect = img.getBoundingClientRect();
+    if (rect.top < window.innerHeight) {
+      issues.push({
+        issue: 'lazy-loaded image in viewport',
+        element: img.outerHTML.substring(0, 200),
+        fix: 'Remove loading="lazy" from this image — it is in the initial viewport and may be the LCP element',
+      });
+    }
+  });
+  // Check for LCP-candidate images missing fetchpriority
+  document.querySelectorAll('img:not([fetchpriority])').forEach(img => {
+    const rect = img.getBoundingClientRect();
+    if (rect.top < window.innerHeight && rect.width * rect.height > 50000) {
+      issues.push({
+        issue: 'large viewport image without fetchpriority',
+        element: img.outerHTML.substring(0, 200),
+        fix: 'Add fetchpriority="high" to this image — it is large and visible in the initial viewport',
+      });
+    }
+  });
+  // Check for render-blocking scripts in head
+  document
+    .querySelectorAll(
+      'head script:not([async]):not([defer]):not([type="module"])',
+    )
+    .forEach(script => {
+      if (script.src) {
+        issues.push({
+          issue: 'render-blocking script in head',
+          element: script.outerHTML.substring(0, 200),
+          fix: 'Add async or defer attribute, or move to end of body',
+        });
+      }
+    });
+  return {issueCount: issues.length, issues};
+};
+```

package/skills/debug-optimize-lcp/references/optimization-strategies.md ADDED Viewed

@@ -0,0 +1,38 @@
+# LCP Optimization Strategies
+## 1. Eliminate Resource Load Delay
+**Goal**: Ensure the LCP resource starts loading as early as possible.
+- **Early Discovery**: Ensure the LCP resource is discoverable in the initial HTML document response (not dynamically added by JS or hidden in `data-src`).
+- **Preload**: Use `<link rel="preload">` with `fetchpriority="high"` for critical images or fonts.
+- **Avoid Lazy Loading**: Never set `loading="lazy"` on the LCP image.
+- **Fetch Priority**: Use `fetchpriority="high"` on the `<img>` tag.
+- **Same Origin**: Host critical resources on the same origin or use `<link rel="preconnect">`.
+## 2. Eliminate Element Render Delay
+**Goal**: Ensure the LCP element can render immediately after its resource has finished loading.
+- **Minimize Render-Blocking CSS**: Inline critical CSS and defer non-critical CSS. Ensure the stylesheet is smaller than the LCP resource.
+- **Minimize Render-Blocking JS**: Avoid synchronous scripts in the `<head>`. Inline very small scripts.
+- **Server-Side Rendering (SSR)**: Deliver the full HTML markup from the server so image resources are discoverable immediately.
+- **Break Up Long Tasks**: Prevent large JavaScript tasks from blocking the main thread during rendering.
+## 3. Reduce Resource Load Duration
+**Goal**: Reduce the time spent transferring the bytes of the resource.
+- **Optimize Resource Size**: Serve optimal image sizes, use modern formats (AVIF, WebP), and compress images/fonts.
+- **Geographic Proximity (CDN)**: Use a Content Delivery Network to get servers closer to users.
+- **Reduce Contention**: Use `fetchpriority="high"` to prevent lower-priority resources from competing for bandwidth.
+- **Caching**: Use efficient `Cache-Control` policies.
+## 4. Reduce Time to First Byte (TTFB)
+**Goal**: Deliver the initial HTML as quickly as possible.
+- **Minimize Redirects**: Avoid multiple redirects from advertisements or shortened links.
+- **CDN Caching**: Cache static HTML documents at the edge.
+- **Edge Computing**: Move dynamic logic to the edge to avoid trips to the origin server.
+- **Back/Forward Cache**: Ensure pages are eligible for bfcache.

package/skills/memory-leak-debugging/SKILL.md ADDED Viewed

@@ -0,0 +1,50 @@
+---
+name: memory-leak-debugging
+description: Diagnoses and resolves memory leaks in JavaScript/Node.js applications. Use when a user reports high memory usage, OOM errors, or wants to analyze heapsnapshots or run memory leak detection tools like memlab.
+---
+# Memory Leak Debugging
+This skill provides expert guidance and workflows for finding, diagnosing, and fixing memory leaks in JavaScript and Node.js applications.
+## Core Principles
+- **Prefer `memlab`:** Do NOT attempt to read raw `.heapsnapshot` files directly, as they are extremely large and will consume too many tokens. Always recommend and use `memlab` to process snapshots and identify leak traces.
+- **Isolate the Leak:** Determine if the leak is in the browser (client-side) or Node.js (server-side).
+- **Common Culprits:** Look for detached DOM nodes, unhandled closures, global variables, event listeners not being removed, and caches growing unbounded. _Note: Detached DOM nodes are sometimes intentional caches; always ask the user before nulling them._
+## Workflows
+### 1. Capturing Snapshots
+When investigating a frontend web application memory leak, utilize the `chrome-devtools-mcp` tools to interact with the application and take snapshots.
+- Use tools like `click`, `navigate_page`, `fill`, etc., to manipulate the page into the desired state.
+- Revert the page back to the original state after interactions to see if memory is released.
+- Repeat the same user interactions 10 times to amplify the leak.
+- Use `take_heapsnapshot` to save `.heapsnapshot` files to disk at baseline, target (after actions), and final (after reverting actions) states.
+### 2. Using Memlab to Find Leaks (Recommended)
+Once you have generated `.heapsnapshot` files using `take_heapsnapshot`, use `memlab` to automatically find memory leaks.
+- Read [references/memlab.md](references/memlab.md) for how to use `memlab` to analyze the generated heapsnapshots.
+- Do **not** read raw `.heapsnapshot` files using `read_file` or `cat`.
+### 3. Identifying Common Leaks
+When you have found a leak trace (e.g., via `memlab` output), you must identify the root cause in the code.
+- Read [references/common-leaks.md](references/common-leaks.md) for examples of common memory leaks and how to fix them.
+### 4. Fallback: Comparing Snapshots Manually
+If `memlab` is not available, you MUST use the fallback script in the references directory to compare two `.heapsnapshot` files and identify the top growing objects and common leak types.
+Run the script using Node.js:
+```bash
+node skills/memory-leak-debugging/references/compare_snapshots.js <baseline.heapsnapshot> <target.heapsnapshot>
+```
+The script will analyze and output the top growing objects by size and highlight the 3 most common types of memory leaks (e.g., Detached DOM nodes, closures, Contexts) if they are present.

package/skills/memory-leak-debugging/references/common-leaks.md ADDED Viewed

@@ -0,0 +1,33 @@
+# Common Memory Leaks
+When analyzing a retainer trace from `memlab`, look for these common patterns in the codebase:
+## 1. Uncleared Event Listeners
+Event listeners attached to global objects (like `window` or `document`) or long-living objects prevent garbage collection of the objects referenced in their callbacks.
+**Fix:** Always call `removeEventListener` when a component unmounts or the listener is no longer needed.
+## 2. Detached DOM Nodes
+A DOM node is removed from the document tree but is still referenced by a JavaScript variable. While detachedness is a good signal for a memory leak, it's not always a bug. For example, websites sometimes intentionally cache detached navigation trees.
+**Fix:** Signal the detached nodes to the user first. **Ask the user first** before nulling the references or changing the code, as the detached nodes might be part of an intentional cache. If confirmed as a leak, ensure variables holding DOM references are set to `null` when the node is removed, or limit their scope.
+## 3. Unintentional Global Variables
+Variables declared without `var`, `let`, or `const` (in non-strict mode) or explicitly attached to `window` remain in memory forever.
+**Fix:** Use strict mode, properly declare variables, and avoid global state.
+## 4. Closures
+Closures can unintentionally keep references to large objects in their outer scope.
+**Fix:** Nullify large objects when they are no longer needed, or refactor the closure to not capture unnecessary variables.
+## 5. Unbounded Caches or Arrays
+Data structures used for caching (like objects, Arrays, or Maps) that grow without limits.
+**Fix:** Implement caching limits, use LRU caches, or use `WeakMap`/`WeakSet` for data associated with object lifecycles.

package/skills/memory-leak-debugging/references/compare_snapshots.js ADDED Viewed

@@ -0,0 +1,109 @@
+/**
+ * @license
+ * Copyright 2025 Google LLC
+ * SPDX-License-Identifier: Apache-2.0
+ */
+import * as fs from 'node:fs';
+function parseSnapshot(filePath) {
+  console.log(`Loading ${filePath}...`);
+  const data = JSON.parse(fs.readFileSync(filePath, 'utf8'));
+  const strings = data.strings;
+  const nodes = data.nodes;
+  const nodeFields = data.snapshot.meta.node_fields;
+  const nodeFieldCount = nodeFields.length;
+  const typeOffset = nodeFields.indexOf('type');
+  const nameOffset = nodeFields.indexOf('name');
+  const sizeOffset = nodeFields.indexOf('self_size');
+  const nodeTypes = data.snapshot.meta.node_types[typeOffset];
+  const counts = {};
+  const sizes = {};
+  for (let i = 0; i < nodes.length; i += nodeFieldCount) {
+    const typeIdx = nodes[i + typeOffset];
+    const typeName = nodeTypes[typeIdx];
+    const nameIdx = nodes[i + nameOffset];
+    const name = typeof nameIdx === 'number' ? strings[nameIdx] : nameIdx;
+    const size = nodes[i + sizeOffset];
+    // Ignore native primitives/arrays that clutter the output unless specifically looking for them
+    if (
+      typeName === 'string' ||
+      typeName === 'number' ||
+      typeName === 'array'
+    ) {
+      continue;
+    }
+    const key = `${typeName}::${name}`;
+    counts[key] = (counts[key] || 0) + 1;
+    sizes[key] = (sizes[key] || 0) + size;
+  }
+  return {counts, sizes};
+}
+const [, , file1, file2] = process.argv;
+if (!file1 || !file2) {
+  console.error(
+    'Usage: node compare_snapshots.js <baseline.heapsnapshot> <target.heapsnapshot>',
+  );
+  process.exit(1);
+}
+try {
+  const snap1 = parseSnapshot(file1);
+  const snap2 = parseSnapshot(file2);
+  const diffs = [];
+  for (const key in snap2.counts) {
+    const count1 = snap1.counts[key] || 0;
+    const count2 = snap2.counts[key];
+    const size1 = snap1.sizes[key] || 0;
+    const size2 = snap2.sizes[key];
+    if (count2 > count1) {
+      diffs.push({
+        key,
+        countDiff: count2 - count1,
+        sizeDiff: size2 - size1,
+      });
+    }
+  }
+  diffs.sort((a, b) => b.sizeDiff - a.sizeDiff);
+  console.log('\n--- Top 10 growing objects by size ---');
+  diffs.slice(0, 10).forEach(d => {
+    console.log(`${d.key}: +${d.countDiff} objects, +${d.sizeDiff} bytes`);
+  });
+  // Look for common leak indicators
+  const commonLeaks = diffs.filter(
+    d =>
+      d.key.toLowerCase().includes('detached') ||
+      d.key.toLowerCase().includes('html') ||
+      d.key.toLowerCase().includes('eventlistener') ||
+      d.key.toLowerCase().includes('context') ||
+      d.key.toLowerCase().includes('closure'),
+  );
+  commonLeaks.sort((a, b) => b.countDiff - a.countDiff);
+  console.log('\n--- Top 3 most common types of memory leaks found ---');
+  if (commonLeaks.length === 0) {
+    console.log('No common DOM or Closure leaks detected.');
+  } else {
+    commonLeaks.slice(0, 3).forEach(d => {
+      console.log(`${d.key}: +${d.countDiff} objects, +${d.sizeDiff} bytes`);
+    });
+  }
+} catch (error) {
+  console.error(
+    'Error parsing snapshots. They might be too large for JSON.parse or invalid.',
+  );
+  console.error(error.message);
+}

package/skills/memory-leak-debugging/references/memlab.md ADDED Viewed

@@ -0,0 +1,29 @@
+# Using Memlab
+[Memlab](https://facebook.github.io/memlab/) is an E2E testing and analysis framework for finding JavaScript memory leaks.
+## Important Rule
+**NEVER read raw `.heapsnapshot` files directly.** They are too large and will exceed context limits. Always use `memlab` commands to analyze them.
+## Analyzing Snapshots
+You can use the `take_heapsnapshot` tool provided by the `chrome-devtools-mcp` extension to generate heap snapshots during an investigation. To find leaks, you generally need 3 snapshots:
+1.  **Baseline:** Before the suspect action.
+2.  **Target:** After the suspect action.
+3.  **Final:** After reverting the suspect action (e.g., closing a modal, navigating away).
+Once you have these 3 snapshots saved to disk, you can use `memlab` to find leaks:
+```bash
+npx memlab find-leaks --baseline <path-to-baseline> --target <path-to-target> --final <path-to-final>
+```
+You can also parse a single snapshot to find the largest objects or explore it individually:
+```bash
+npx memlab analyze snapshot --snapshot <path-to-snapshot>
+```
+Memlab will output the retainer traces for identified leaks. Use these traces to guide your search in the codebase.

package/skills/troubleshooting/SKILL.md ADDED Viewed

@@ -0,0 +1,98 @@
+---
+name: troubleshooting
+description: Uses Chrome DevTools MCP and documentation to troubleshoot connection and target issues. Trigger this skill when list_pages, new_page, or navigate_page fail, or when the server initialization fails.
+---
+## Troubleshooting Wizard
+You are acting as a troubleshooting wizard to help the user configure and fix their Chrome DevTools MCP server setup. When this skill is triggered (e.g., because `list_pages`, `new_page`, or `navigate_page` failed, or the server wouldn't start), follow this step-by-step diagnostic process:
+### Step 1: Find and Read Configuration
+Your first action should be to locate and read the MCP configuration file. Search for the following files in the user's workspace: `.mcp.json`, `gemini-extension.json`, `.claude/settings.json`, `.vscode/launch.json`, or `.gemini/settings.json`.
+If you find a configuration file, read and interpret it to identify potential issues such as:
+- Incorrect arguments or flags.
+- Missing environment variables.
+- Usage of `--autoConnect` in incompatible environments.
+If you cannot find any of these files, only then should you ask the user to provide their configuration file content.
+### Step 2: Triage Common Connection Errors
+Before reading documentation or suggesting configuration changes, check if the error message matches one of the following common patterns.
+#### Error: `Could not find DevToolsActivePort`
+This error is highly specific to the `--autoConnect` feature. It means the MCP server cannot find the file created by a running, debuggable Chrome instance. This is not a generic connection failure.
+Your primary goal is to guide the user to ensure Chrome is running and properly configured. Do not immediately suggest switching to `--browserUrl`. Follow this exact sequence:
+1. **Ask the user to confirm that the correct Chrome version** (e.g., "Chrome Canary" if the error mentions it) is currently running.
+2. **If the user confirms it is running, instruct them to enable remote debugging.** Be very specific about the URL and the action: "Please open a new tab in Chrome, navigate to `chrome://inspect/#remote-debugging`, and make sure the 'Enable remote debugging' checkbox is checked."
+3. **Once the user confirms both steps, your only next action should be to call the `list_pages` tool.** This is the simplest and safest way to verify if the connection is now successful. Do not retry the original, more complex command yet.
+4. **If `list_pages` succeeds, the problem is resolved.** If it still fails with the same error, then you can proceed to the more advanced steps like suggesting `--browserUrl` or checking for sandboxing issues.
+#### Symptom: Server starts but creates a new empty profile
+If the server starts successfully but `list_pages` returns an empty list or creates a new profile instead of connecting to the existing Chrome instance, check for typos in the arguments.
+- **Check for flag typos:** For example, `--autoBronnect` instead of `--autoConnect`.
+- **Verify the configuration:** Ensure the arguments match the expected flags exactly.
+#### Symptom: Missing Tools / Only 9 tools available
+If the server starts successfully but only a limited subset of tools (like `list_pages`, `get_console_message`, `lighthouse_audit`, `take_heapsnapshot`) are available, this is likely because the MCP client is enforcing a **read-only mode**.
+All tools in `chrome-devtools-mcp` are annotated with `readOnlyHint: true` (for safe, non-modifying tools) or `readOnlyHint: false` (for tools that modify browser state, like `emulate`, `click`, `navigate_page`). To access the full suite of tools, the user must disable read-only mode in their MCP client (e.g., by exiting "Plan Mode" in Gemini CLI or adjusting their client's tool safety settings).
+#### Symptom: Extension tools are missing or extensions fail to load
+If the tools related to extensions (like `install_extension`) are not available, or if the extensions you load are not functioning:
+1. **Check for the `--categoryExtensions` flag**: Ensure this flag is passed in the MCP server configuration to enable the extension category tools.
+2. **Make sure the MCP server in configured to launch Chrome instead of connecting to an instance**: Chrome before 149 is not able to load extensions when connecting to an existing instance (`--auto-connect`, `--browserUrl`).
+#### Other Common Errors
+Identify other error messages from the failed tool call or the MCP initialization logs:
+- `Target closed`
+- "Tool not found" (check if they are using `--slim` which only enables navigation and screenshot tools).
+- `ProtocolError: Network.enable timed out` or `The socket connection was closed unexpectedly`
+- `Error [ERR_MODULE_NOT_FOUND]: Cannot find module`
+- Any sandboxing or host validation errors.
+### Step 3: Read Known Issues
+Read the contents of https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/troubleshooting.md to map the error to a known issue. Pay close attention to:
+- Sandboxing restrictions (macOS Seatbelt, Linux containers).
+- WSL requirements.
+- `--autoConnect` handshakes, timeouts, and requirements (requires **running** Chrome 144+).
+### Step 4: Formulate a Configuration
+Based on the exact error and the user's environment (OS, MCP client), formulate the correct MCP configuration snippet. Check if they need to:
+- Pass `--browser-url=http://127.0.0.1:9222` instead of `--autoConnect` (e.g. if they are in a sandboxed environment like Claude Desktop).
+- Enable remote debugging in Chrome (`chrome://inspect/#remote-debugging`) and accept the connection prompt. **Ask the user to verify this is enabled if using `--autoConnect`.**
+- Add `--logFile <absolute_path_to_log_file>` to capture debug logs for analysis.
+- Increase `startup_timeout_ms` (e.g. to 20000) if using Codex on Windows.
+_If you are unsure of the user's configuration, ask the user to provide their current MCP server JSON configuration._
+### Step 5: Run Diagnostic Commands
+If the issue is still unclear, run diagnostic commands to test the server directly:
+- Run `npx chrome-devtools-mcp@latest --help` to verify the installation and Node.js environment.
+- If you need more information, run `DEBUG=* npx chrome-devtools-mcp@latest --logFile=/tmp/cdm-test.log` to capture verbose logs. Analyze the output for errors.
+### Step 6: Check GitHub for Existing Issues
+If https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/troubleshooting.md does not cover the specific error, check if the `gh` (GitHub CLI) tool is available in the environment. If so, search the GitHub repository for similar issues:
+`gh issue list --repo ChromeDevTools/chrome-devtools-mcp --search "<error snippet>" --state all`
+Alternatively, you can recommend that the user checks https://github.com/ChromeDevTools/chrome-devtools-mcp/issues and https://github.com/ChromeDevTools/chrome-devtools-mcp/discussions for help.