feat: add WebExtension debugging support via extensionPath config

[noorez]

Summary

Adds an extensionPath property to Chrome/Edge launch and attach configurations, enabling debugging of unpacked browser extensions (MV2 background pages, MV3 service workers) without manual target picking or workarounds.

Closes #945

---

Background

Issue #945 was closed as out-of-scope citing two blockers:

1. Target type filter — the debugger only accepted page-type CDP targets; service workers were silently skipped (noted as "easy to fix")
2. Non-deterministic extension IDs — source URLs use chrome-extension://<id>/... where <id> changes each session with a fresh profile, making static path mapping configuration impossible (noted as the "hard" blocker)

vscode-firefox-debug solves the equivalent Firefox problem (moz-extension://<uuid>/...) with a UUID-ignoring regex. The same approach works for Chrome.

---

Changes

File	Change
src/configuration.ts	extensionPath: string | null on IChromiumBaseConfiguration (Chrome + Edge, launch + attach)
src/targets/browser/browserLauncher.ts	Injects --load-extension into Chrome args; overrides getFilterForTarget to match extension targets; pins discovered extension ID post-attach
src/targets/browser/browserAttacher.ts	Same target filter override in getTargetFilter
src/targets/browser/browserPathResolver.ts	chrome-extension://<id>/path → extensionPath/path resolution; pinExtensionId() to lock to discovered ID
src/targets/sourcePathResolverFactory.ts	Threads extensionPath through to resolver options
src/build/generate-contributions.ts	extensionPath in shared Chromium base schema; adds "Chrome: Launch Extension" config snippet
src/cdp/connection.ts	Unknown-session-id throw → warn+return — Chrome sends Inspector.workerScriptLoaded on the service worker session before createSession() completes, causing a noisy unhandled error
package.nls.json	NLS strings for new config property and snippet

---

How It Works

Target filtering: When extensionPath is set, the CDP target filter accepts service_worker and page targets whose URL starts with chrome-extension://, rejecting all others (normal tabs, devtools, etc.).

Source map resolution: A UUID-ignoring regex initially matches any 32-character extension ID. Once the main target attaches, the real ID is extracted from the target URL and pinned — all subsequent chrome-extension:// source URLs are matched only against that exact origin, so other loaded extensions cannot interfere.

1. Target type filter — the debugger only accepted page-type CDP targets; service workers were silently skipped (noted as "easy to fix")
2. Non-deterministic extension IDs — source URLs use chrome-extension://<id>/... where <id> changes each session with a fresh profile, making static path mapping configuration impossible (noted as the "hard" blocker)

vscode-firefox-debug solves the equivalent Firefox problem (moz-extension://<uuid>/...) with a UUID-ignoring regex. The same approach works for Chrome.

---

Changes

File	Change
src/configuration.ts	extensionPath: string | null on IChromiumBaseConfiguration (Chrome + Edge, launch + attach)
src/targets/browser/browserLauncher.ts	Injects --load-extension into Chrome args; overrides getFilterForTarget to match extension targets; pins discovered extension ID post-attach
src/targets/browser/browserAttacher.ts	Same target filter override in getTargetFilter
src/targets/browser/browserPathResolver.ts	chrome-extension://<id>/path → extensionPath/path resolution; pinExtensionId() to lock to discovered ID
src/targets/sourcePathResolverFactory.ts	Threads extensionPath through to resolver options
src/build/generate-contributions.ts	extensionPath in shared Chromium base schema; adds "Chrome: Launch Extension" config snippet
src/cdp/connection.ts	Unknown-session-id throw → warn+return — Chrome sends Inspector.workerScriptLoaded on the service worker session before createSession() completes, causing a noisy unhandled error
package.nls.json	NLS strings for new config property and snippet

---

How It Works

Target filtering: When extensionPath is set, the CDP target filter accepts service_worker and page targets whose URL starts with chrome-extension://, rejecting all others (normal tabs, devtools, etc.).

Source map resolution: A UUID-ignoring regex initially matches any 32-character extension ID. Once the main target attaches, the real ID is extracted from the target URL and pinned — all subsequent chrome-extension:// source URLs are matched only against that exact origin, so other loaded extensions cannot interfere.

---

Usage

Launch — VS Code owns Chrome, no external tooling needed:

{
  "type": "pwa-chrome",
  "request": "launch",
  "name": "Debug Extension",
  "extensionPath": "${workspaceFolder}/dist",
  "webRoot": "${workspaceFolder}",
  "sourceMapPathOverrides": {
    "webpack://<name>/./src/*": "${workspaceFolder}/src/*"
  }
}

--load-extension is injected automatically. The debugger attaches to the extension's background service worker or page without any manual target selection.

Attach — bring your own Chrome launcher (web-ext, a shell script, etc.):

{
  "type": "pwa-chrome",
  "request": "attach",
  "port": 9222,
  "name": "Debug Extension (attach)",
  "extensionPath": "${workspaceFolder}/dist",
  "webRoot": "${workspaceFolder}",
  "sourceMapPathOverrides": {
    "webpack://<name>/./src/*": "${workspaceFolder}/src/*"
  }
}

---
Not Included

- Auto-reload on file change — vscode-firefox-debug implements this via reloadDescriptor. The Chrome equivalent requires calling chrome.runtime.reload() via Runtime.evaluate then re-attaching to the new service worker target. Left as a follow-up; web-ext run --target=chromium covers this in the interim.
- Content script first-class support — content scripts run in normal page targets and are already reachable. extensionPath handles source map resolution for them as well when chrome-extension:// URLs appear in their sourcemaps.

---
Testing the Branch

git clone https://github.com/noorez/vscode-js-debug.git
cd vscode-js-debug
git checkout feat/webextension-extensionpath
npm install && npm run compile

Then open an extension workspace with the dev build loaded:

code --extensionDevelopmentPath="$(pwd)/dist" \
     --enable-proposed-api=ms-vscode.js-debug \
     /path/to/your/extension

Add a pwa-chrome launch config with "extensionPath": "${workspaceFolder}/dist" (pointing to your built extension) and press F5. The debugger should attach directly to the service worker — no manual target picking.

Community testing reports very welcome, especially on:
- MV2 background pages
- MV3 service workers
- Microsoft Edge (pwa-msedge)
- Extensions with TypeScript + sourcemaps

[noorez]

@microsoft-github-policy-service agree

[noorez]

hmm...on second thought, is this too lax now? initial testing showed that a real error wasnt allowed to slip through but perhaps some more aggressive timing checks are warranted?

[noorez]

refined in commit: e326e5d