Debugging Client-Side JavaScript with WebStorm 2017.3

Ekaterina Prigara

We have some good news for everyone who is using WebStorm to debug client-side JavaScript apps in Chrome!

The first big news is that starting with Chrome 63, you can now use Chrome DevTools and WebStorm debugger at the same time.

Second, with WebStorm 2017.3 you no longer need an additional Chrome extension to debug apps in WebStorm.

Debugging in WebStorm and in Chrome DevTools at the same time

If you’ve ever tried to open DevTools in the browser while having a debugger opened in WebStorm, or vice versa, you saw that the WebStorm debugger immediately disconnected.

That happened because both WebStorm and DevTools are using the same debug protocol that did not support multi-client debugging. For many years, this Chromium issue was one of the most popular on their tracker. Well, now it’s finally fixed in Chrome 63!

This means that now you can use both the DevTools debugger and the WebStorm debugger at the same time, having their best features at your command.

For example, you can debug your app using WebStorm where you can put the breakpoints right in the source code, and then use the DevTools Elements panel to inspect DOM and styles, or its powerful Network panel to get insights into network performance.

Debugging with Webstorm and Chrome at the same time

Stepping through the code is synchronized between DevTools and WebStorm. Once a breakpoint is hit, you can use the step and resume actions in either tool – both tools will show the execution point in the code and update the call stacks and the variables view.

Easy start with JavaScript debugger

As of WebStorm 2017.3, you no longer have to install JetBrains’ Chrome extension to debug your client-side apps in the IDE.

To debug the app, all you have to do now is create a new JavaScript debug configuration and specify the URL your app is running on. Then put the breakpoints in the code and start the debug configuration. WebStorm will open a new instance of Chrome (with the remote debugging on) and seamlessly attach to it.

The WebStorm team

Comments below can no longer be edited.

34 Responses to Debugging Client-Side JavaScript with WebStorm 2017.3

  1. PC says:

    January 8, 2018

    This is so cool! Will the same be available on IDEA?

    • Ekaterina Prigara says:

      January 8, 2018

      Yes, it works the same in IntelliJ IDEA with Chrome 63.

      • Nate says:

        January 10, 2018

        This is amazing!

        I have IntelliJ 2017.3.3 Build 173.4301.14 and it does not seem to be working, it still searches for the browser plugin.

        I have confirmed that Webstorm works, so it’s not a Chrome issue.

        Is there a different version of IntelliJ that I should be using?

        • Ekaterina Prigara says:

          January 11, 2018

          If you’re using a Live Edit feature, you still need a browser extension. If you don’t really use it, please make sure that all the checkboxes in Preferences | Build, Execution, Deployment | Debugger | Live Edit are unchecked or simply remove the Live Edit plugin from IJ and re-create a debug configuration. You can find a bit more details about it in this blog post: https://blog.jetbrains.com/webstorm/2017/10/webstorm-2017-3-eap-173-3415/

  2. Porfirio Chávez says:

    January 8, 2018

    Exist the possibilty to eval objects in console like chrome?

    On type name var always show ‘object’ word. And hold mouse pointer on it and then wait for emergent info takes a lot of time.

    Exist a shortcut for see it ?

    • Ekaterina Prigara says:

      January 9, 2018

      You can evaluate expressions right in the editor during the debug session. The action is called Quick evaluate expression: the shortcut on macOS is Alt-Cmd-F8 and on Windows and Linux it’s Alt-Ctrl-F8.
      Is that something you were looking for?

  3. Antonio says:

    January 8, 2018

    Do you know if this works across sourcemaps too?

    • Ekaterina Prigara says:

      January 9, 2018

      It should. The app I was using for the gifs is in React and is compiled using Babel and Webpack.

  4. Louis says:

    January 10, 2018

    It sounds awesome, thanks! Will it work with the React Native Debugger?

    • Ekaterina Prigara says:

      January 11, 2018

      Should work if Chrome is selected as a Debugger process in the React Native run/debug configuration.

  5. Yaroslav Admin says:

    January 11, 2018

    Is it possible to attach with debugger to running Chrome instance instead of starting a new one? When I click on Debugger icon in WebStorm it starts new Chrome instance. But I would like to debug code already running in my main Chrome window.

    • Ekaterina Prigara says:

      January 11, 2018

      Chrome needs to run in a remote debug mode, that is why a new instance is started.
      You can use JetBrains IDE Support Chrome extension, with it WebStorm will be able to connect to a running instance (for that you will also need to check Update application in Chrome in Preferences | Build, Execution, Deployment | Debugger | Live Edit).

      • Yaroslav Admin says:

        January 11, 2018

        Yes, it works. Thank you for a quick reply!

  6. Julian says:

    January 12, 2018

    Thanks for this.

    I’ve still got the problem that Chrome (Linux) starts with the wrong profile. Even after following your other guides. Chrome always opens without any profile I got.

    • Ekaterina Prigara says:

      January 12, 2018

      Hello, have you followed these steps? https://www.jetbrains.com/help/webstorm/debugging-javascript-in-chrome.html#ws_js_debug_chrome_default_profile

      • Julian says:

        January 12, 2018

        Thanks for your reply and yes, I tried it.

        Here is a screenshot:

        https://s10.postimg.org/5v4kz5pkp/Screenshot_from_2018-01-12_16-08-29.png

        “Profile 2” is non of the profiles I use, it’s a non existing profile.

        • Konstantin Ulitin says:

          January 15, 2018

          Hello, Julian. I think there’s a confusion of chrome profile and user data dir. “Use custom profile directory” should point to user data directory, not chrome profile (we’ll rename it). Chrome profile directory is inside user data directory. Chrome can’t start with debugging port open if there’s an instance running from the same user data directory. So, if you want all your settings from Chrome to be available on debug (i.e. have your profiles loaded), you need to either
          1. specify ~/.config/google-chrome in “Use custom profile directory” field and ensure that no Chrome is running when you start debug, or
          2. copy your ~/.config/google-chrome to another location and set it in “Use custom profile directory” field.

          • Julian says:

            January 15, 2018

            Ahhh, you are so awesome! This is one of the features I missed in the past and now it works. You made my year, thanks a lot!

  7. lmame says:

    January 12, 2018

    That is very cool… It even works for unit tests (karma), it is something I was waiting for a long time!

  8. nenti says:

    January 15, 2018

    Really nice feature. Can you make this work with react-native-debugger aswell? Having the posibility to set breakpoints and inspection inside webstorm while debugging react-native would be a major productivit booster of not requiring to switch back and forth between tools, finding the correct source files and refreshing the app for the testcase.

  9. J says:

    January 21, 2018

    Hello, It seems amazing.
    But I’m doing some thing wrong, it doesn’t work for me.

    I use “npm start” with this config:

    “start”: “webpack-dev-server –inline –progress –port 8080”

    When I start debug mode, WebStorm opens a new instance of Chrome,
    but the debugger doesn’t stop at the breakpoints.

    What is wrong?
    Thaks.

    • J says:

      January 21, 2018

      I found the problem.
      In the file webpack.dev.js I don’t know why, the value devtool was set to ‘cheap-module-eval-source-map’.

      I change devtool from ‘cheap-module-eval-source-map’ to ‘source-map’.

      Now it works!

      • Ekaterina Prigara says:

        January 22, 2018

        Great that it works now 🙂

    • Ekaterina Prigara says:

      January 22, 2018

      Please contact our tech support and provide a bit more details: where exactly the breakpoints are put? what kind of source maps are enabled in your webpack configuration file? Please also try reloading the page in the browser: the breakpoints in the code that is executed on the page load might not be hit when you load the app for the first time.

  10. Lyubimov Roman says:

    January 30, 2018

    Does it work with Angular CLI? Can’t make it work. Do I need make an additional configuration?

    • Lyubimov Roman says:

      January 30, 2018

      Oh, ok, it works with chrome plugin. But you sad “Second, with WebStorm 2017.3 you no longer need an additional Chrome extension to debug apps in WebStorm.”

      • Ekaterina Prigara says:

        January 30, 2018

        Debugging Angular applications works with or without Chrome extension. Please have a look at this tutorial about debugging Angular CLI apps: https://blog.jetbrains.com/webstorm/2017/01/debugging-angular-apps/

        • Lyubimov Roman says:

          January 30, 2018

          It do work with chrome extension but doesn’t without it.
          I saw this page, first link to video says that I need to install chrome extension. So, do I need to install or maybe uninstall it before? I use Ubuntu with Chrome 63.

          • Ekaterina Prigara says:

            January 30, 2018

            Please contact our technical support to help us investigate why it doesn’t work for you without the extension. Thank you!
            The extension, as this blog post says, is not required for debugging if you’re using WebStorm 2017.3. The video was recorded over a year ago, however, we have updated its description to say that extension is not required anymore.

  11. Maximilian Schmid says:

    April 24, 2018

    Debugger just doesn’t stop at breakpoints with Chrome 66, Webstorm 2018.1 on macOS High Sierra.

    • Ekaterina Prigara says:

      April 24, 2018

      Hello Maximilian,
      Please provide a bit more details: what kind of app do you have? Where the breakpoints are?
      If possible, please share with us a sample project that demonstrates the problem. Thank you!

  12. Jimmy says:

    May 29, 2019

    I was confused by the usage of the word ‘seamlessly’, expecting it to be… you know, seamless. Silly me.

    Because it turned out to be quite the opposite of seamless. A migraine inducing nightmare.

    • Ekaterina Prigara says:

      June 3, 2019

      Hello Jimmy, sorry to hear that you’ve had such a bad experience. We would appreciate any details about the problems you’ve had.