vscode-chrome-debug

## :rotating_light: Important This extension has been deprecated as Visual Studio Code now has a [bundled JavaScript Debugger](https://github.com/microsoft/vscode-js-debug) that covers the same functionality. It is a debugger that debugs Node.js, Chrome, Edge, WebView2, VS Code extensions, and more. You can safely un-install this extension and you will still be able to have the functionality you need. Please file any issues you encounter in [that repository](https://github.com/microsoft/vscode-js-debug). ---

VS Code - Debugger for Chrome

Debug your JavaScript code running in Google Chrome from VS Code.

A VS Code extension to debug your JavaScript code in the Google Chrome browser, or other targets that support the [Chrome DevTools Protocol](https://chromedevtools.github.io/debugger-protocol-viewer/). **Supported features** * Setting breakpoints, including in source files when source maps are enabled * Stepping, including with the buttons on the Chrome page * The Locals pane * Debugging eval scripts, script tags, and scripts that are added dynamically * Watches * Console **Unsupported scenarios** * Debugging web workers * Debugging Chrome extensions * Any features that aren't script debugging ## Getting Started 1. [Install the extension](https://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrome) 2. Open the folder containing the project you want to work on. ## Using the debugger When your launch config is set up, you can debug your project. Pick a launch config from the dropdown on the Debug pane in Code. Press the play button or F5 to start. ### Configuration The extension operates in two modes - it can launch an instance of Chrome navigated to your app, or it can attach to a running instance of Chrome. Both modes requires you to be serving your web application from local web server, which is started from either a VS Code task or from your command-line. Using the `url` parameter you simply tell VS Code which URL to either open or launch in Chrome. Just like when using the Node debugger, you configure these modes with a `.vscode/launch.json` file in the root directory of your project. You can create this file manually, or Code will create one for you if you try to run your project, and it doesn't exist yet. > **Tip**: See recipes for debugging different frameworks here: https://github.com/Microsoft/vscode-recipes ### Launch Two example `launch.json` configs with `"request": "launch"`. You must specify either `file` or `url` to launch Chrome against a local file or a url. If you use a url, set `webRoot` to the directory that files are served from. This can be either an absolute path or a path using `${workspaceFolder}` (the folder open in Code). `webRoot` is used to resolve urls (like "http://localhost/app.js") to a file on disk (like `/Users/me/project/app.js`), so be careful that it's set correctly. ```json { "version": "0.1.0", "configurations": [ { "name": "Launch localhost", "type": "chrome", "request": "launch", "url": "http://localhost/mypage.html", "webRoot": "${workspaceFolder}/wwwroot" }, { "name": "Launch index.html", "type": "chrome", "request": "launch", "file": "${workspaceFolder}/index.html" }, ] } ``` If you want to use a different installation of Chrome, you can also set the `runtimeExecutable` field with a path to the Chrome app. ### Attach With `"request": "attach"`, you must launch Chrome with remote debugging enabled in order for the extension to attach to it. Here's how to do that: __Windows__ * Right click the Chrome shortcut, and select properties * In the "target" field, append `--remote-debugging-port=9222` * Or in a command prompt, execute `/chrome.exe --remote-debugging-port=9222` __macOS__ * In a terminal, execute `/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222` __Linux__ * In a terminal, launch `google-chrome --remote-debugging-port=9222` If you have another instance of Chrome running and don't want to restart it, you can run the new instance under a separate user profile with the `--user-data-dir` option. Example: `--user-data-dir=/tmp/chrome-debug`. This is the same as using the `userDataDir` option in a launch-type config. Launch Chrome and navigate to your page. An example `launch.json` file for an "attach" config. ```json { "version": "0.1.0", "configurations": [ { "name": "Attach to url with files served from ./out", "type": "chrome", "request": "attach", "port": 9222, "url": "", "webRoot": "${workspaceFolder}/out" } ] } ``` ### Chrome user profile note (`Cannot connect to the target: connect ECONNREFUSED`) Normally, if Chrome is already running when you start debugging with a launch config, then the new instance won't start in remote debugging mode. So by default, the extension launches Chrome with a separate user profile in a temp folder. Use the `userDataDir` launch config field to override or disable this. If you are using the `runtimeExecutable` field, this isn't enabled by default, but you can forcibly enable it with `"userDataDir": true`. If you are using an attach config, make sure you close other running instances of Chrome before launching a new one with `--remote-debugging-port`. Or, use a new profile with the `--user-data-dir` flag yourself. For other troubleshooting tips for this error, [see below](#cannot-connect-to-the-target:-connect-ECONNREFUSED-127.0.0.1:9222). ### Errors from chrome-error://chromewebdata If you see errors with a location like `chrome-error://chromewebdata/` in the error stack, these errors are not from the extension or from your app - they are usually a sign that Chrome was not able to load your app. When you see these errors, first check whether Chrome was able to load your app. Does Chrome say "This site can't be reached" or something similar? You must start your own server to run your app. Double-check that your server is running, and that the url and port are configured correctly. ### Other targets You can also theoretically attach to other targets that support the same Chrome Debugging protocol, such as Electron or Cordova. These aren't officially supported, but should work with basically the same steps. You can use a launch config by setting `"runtimeExecutable"` to a program or script to launch, or an attach config to attach to a process that's already running. If Code can't find the target, you can always verify that it is actually available by navigating to `http://localhost:/json` in a browser. If you get a response with a bunch of JSON, and can find your target page in that JSON, then the target should be available to this extension. ### Examples See our wiki page for some configured example apps: [Examples](https://github.com/Microsoft/vscode-chrome-debug/wiki/Examples) ### Other optional launch config fields * `trace`: When true, the adapter logs its own diagnostic info to a file. The file path will be printed in the Debug Console. This is often useful info to include when filing an issue on GitHub. If you set it to "verbose", it will also log to the console. * `runtimeExecutable`: Workspace relative or absolute path to the runtime executable to be used. If not specified, Chrome will be used from the default install location. * `runtimeArgs`: Optional arguments passed to the runtime executable. * `env`: Optional dictionary of environment key/value pairs. * `cwd`: Optional working directory for the runtime executable. * `userDataDir`: Normally, if Chrome is already running when you start debugging with a launch config, then the new instance won't start in remote debugging mode. So by default, the extension launches Chrome with a separate user profile in a temp folder. Use this option to set a different path to use, or set to false to launch with your default user profile. * `url`: On a 'launch' config, it will launch Chrome at this URL. * `urlFilter`: On an 'attach' config, or a 'launch' config with no 'url' set, search for a page with this url and attach to it. It can also contain wildcards, for example, `"localhost:*/app"` will match either `"http://localhost:123/app"` or `"http://localhost:456/app"`, but not `"https://stackoverflow.com"`. * `targetTypes`: On an 'attach' config, or a 'launch' config with no 'url' set, set a list of acceptable target types from the default `["page"]`. For example, if you are attaching to an Electron app, you might want to set this to `["page", "webview"]`. A value of `null` disables filtering by target type. * `sourceMaps`: By default, the adapter will use sourcemaps and your original sources whenever possible. You can disable this by setting `sourceMaps` to false. * `pathMapping`: This property takes a mapping of URL paths to local paths, to give you more flexibility in how URLs are resolved to local files. `"webRoot": "${workspaceFolder}"` is just shorthand for a pathMapping like `{ "/": "${workspaceFolder}" }`. * `smartStep`: Automatically steps over code that doesn't map to source files. Especially useful for debugging with async/await. * `disableNetworkCache`: If false, the network cache will be NOT disabled. It is disabled by default. * `showAsyncStacks`: If true, callstacks across async calls (like `setTimeout`, `fetch`, resolved Promises, etc) will be shown. * `breakOnLoad`: Experimental. If true, the debug adapter will attempt to set breakpoints in scripts before they are loaded, so it can hit breakpoints at the beginnings of those scripts. Has a perf impact. * `breakOnLoadStrategy`: The strategy used for `breakOnLoad`. Options are "Instrument" or "Regex". Instrument "[tells] Chrome to pause as each script is loaded, resolving sourcemaps and setting breakpoints" Regex "[s]ets breakpoints optimistically in files with the same name as the file in which the breakpoint is set." ## Skip files / Blackboxing / Ignore files You can use the `skipFiles` property to ignore/blackbox specific files while debugging. For example, if you set `"skipFiles": ["jquery.js"]`, then you will skip any file named 'jquery.js' when stepping through your code. You also won't break on exceptions thrown from 'jquery.js'. This works the same as "blackboxing scripts" in Chrome DevTools. The supported formats are: * The name of a file (like `jquery.js`) * The name of a folder, under which to skip all scripts (like `node_modules`) * A path glob, to skip all scripts that match (like `node_modules/react/*.min.js`) ## Page refreshing This debugger also enables you to refresh your target by simply hitting the restart button in the debugger UI. Additionally you can map the refresh action to your favorite keyboard shortcut by adding the following key mapping to [Key Bindings](https://code.visualstudio.com/docs/getstarted/keybindings): ```json { "key": "ctrl+r", "command": "workbench.action.debug.restart", "when": "inDebugMode" } ``` Read more here https://github.com/Microsoft/vscode-chrome-debug-core/issues/91#issuecomment-265027348 ## Sourcemaps The debugger uses sourcemaps to let you debug with your original sources, but sometimes the sourcemaps aren't generated properly and overrides are needed. In the config we support `sourceMapPathOverrides`, a mapping of source paths from the sourcema