Breakpoints not working inside Chrome devtools since v10.12.0

[ehmicky]

• Version: v10.12.0
• Platform: Linux my-laptop 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
• Chrome version: 69.0.3497.100 (V8 6.9.427.23)

This might be related to #23688 but I believe this might contain more detailed information.

Breakpoints set inside Chrome devtools do not stop code execution anymore since v10.12.0. It works with v10.11.0 though. debugger statements work (only breakpoints set in the Chrome devtools UI do not work).

Example file index.js:

console.log('start');
debugger;
console.log('breakpoint');

Steps to reproduce:

• Inside Chrome, go to chrome://inspect/#devices then click on Open dedicated DevTools for Node
• Using Node v10.11.0:
  • Run node --inspect-brk index.js. The code stops at the first line.
  • Add a breakpoint to console.log() line by clicking on the left margin
  • Click on Resume script execution (F8): the code stops at debugger statement.
  • Click on Resume script execution (F8): the code stops at console.log() statement.
  • Click on Resume script execution (F8): the code execution ends.
• Using Node v10.12.0:
  • Run node --inspect-brk index.js. The code stops at the first line.
  • Add a breakpoint to console.log() line by clicking on the left margin
  • Click on Resume script execution (F8): the code stops at debugger statement.
  • Click on Resume script execution (F8): the code does not stop at console.log() statement. Instead the code execution ends.

Screencast:

[targos]

I can reproduce. bisecting...

[targos]

I'm having trouble to make it work with any version of Node. Tried 10.12.0, 10.11.0, 10.10.0, 9.11.2 and 8.12.0.
The problem happens with all of them.

[jeremychone]

I had a similar sure with vscode, basically debugging typescript with sourcemap stopped working, and debugging the emitted .js code works, but the file I am debugging is another "read only file" with the wrapper function around.

It looks like node.js 10.12 is "exposing" (not sure the right word here) the wrapped file rather than the original source file, which can throw the debugger off.

All work fine with 10.11

[alexkozy]

I believe that I am responsible for this issue. Node 10.12 reports unified file urls in protocol instead of platform specific paths.
DevTools frontend from Chrome 71 and Chrome 72 should be able to work with such urls, please try to use Chrome dev release if it is possible in your Linux distributive.

[targos]

It works with Chrome 72.

[jeremychone]

Ok, so, if this one is a chrome issue, then, my VSCode debug issue with node 10.12 is not this issue.

[ehmicky]

This issue is solved by Chrome 71 indeed. Thanks!

I am not sure whether to close this issue right away and whether you would prefer to patch Node.js until Chrome 71 is out of beta.

[june07]

Another solution if using NiM is to simply use the 71 DevTools version with whatever browser version you happen to be running. No need to wait for Chrome moving from beta. See here for more details: https://blog.june07.com/nim-custom-devtools-url

[eduardofcr]

I have the same issue.
My configuration:
Debian GNU/Linux 9
google chrome Version 70.0.3538.77 (Official Build) (64-bit)
I was using node 10.13 : did not stop in breakpoints

The solution I found was to downgrade node to 8.12

[Trott]

Chrome 71 is scheduled to exit beta and become stable in early December.

[ehmicky]

It worked with Chrome 71 but I am now experiencing the same issue with Chrome 72.

Google Chrome | 72.0.3610.2 (Official Build) dev (64-bit)
Revision | d1388eea987cd8f0f0e28b3570cded07eebae848-refs/branch-heads/3610@{#8}
OS | Linux
JavaScript | V8 7.2.317

There is a difference though: when I am on the chrome://inspect/#devices page among the two options:

1. Clicking on Open dedicated DevTools for Node
2. Clicking on Remote Target inspect link

Only (1) is experiencing the issue, not (2). However (as opposed to (1)) (2) is inconvenient as each time the process is restarted, I have to manually click on that link again.

I can confirm this is the same issue. Notably it works with Node 10.11.0 but not 10.12.0 (nor 11.2.0).

[cronvel]

I'm still on Chrome 69.
Node 8 is ok, but Node 10 does not support UI breakpoints, only debugger statement breakpoints.
Also in Node 10, the devtools does not mask Node.js source code and it's really boring to get out of async_hook.js and the like.

[ehmicky]

@cronvel It seems like upgrading to Chrome 70 solves the issue (although Chrome 71 seems to create this issue again).

I also had the same issue as @cronvel where blackboxing would not work and I would step in async_hook.js and the like.

[bradisbell]

Broken for me on Chrome v70, Node.js v10.13.0, win x64. Please let me know if there is any additional information I can provide to aid in debugging.

[anmolagar]

breakpoint are not working
Node version 11.1.0

[Biboba]

Same for me on Chrome v70, Node.js v10.13.0, win x64

[shimondoodkin]

currently

need chrome canary, not chrome beta

https://www.google.com/chrome/canary/

[lancelot-c]

Worked for me with Chrome Canary - version 73

[Fmajor]

4.19.23-gentoo
node v10.15.3
in chrome://inspect of 73.0.3683.75 or 74.0.3729.6
The 'Open dedicated DevTools for Node' failed to catch the code (but I can debug the code by click the 'Inspect' in the "Remote Target")

change chrome to 72.0.3626.121, the 'Open dedicated DevTools for Node' function work fine again.
now I lock my chrome version to 72

[felamaslen]

Can confirm "Open dedicated DevTools for Node" doesn't work with Chrome 73.0.3683.86, on Arch Linux. The code is not visible in the sources pane, and breakpoints are not triggered.

[june07]

Reminder that https://blog.june07.com/nim-custom-devtools-url works as a way to utilize previous DevTools versions with 73.0.3683.86... and other combinations as well.

[emamulandalib]

I have found a working example. Please follow the steps:

1. Run file with --inspect. You will find a link like this ws://0.0.0.0:9230/1dc49645-2a4a-4816-891f-7c71a2c99902. This is the token:1dc49645-2a4a-4816-891f-7c71a2c99902 from url.
2. Open the link in Chrome and replace the token by your token:
   chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=localhost:9229/{token}

[legalbridge]

I too have this problem. Please help. When I quit and restart Chrome it works again, but only once. I don't wanna have to restart Chrome every time I change my code.

Chrome Version 73.0.3683.86 (Official Build) (64-bit)

$ npm version { npm: '6.9.0', ares: '1.15.0', cldr: '34.0', http_parser: '2.8.0', icu: '63.1', llhttp: '1.0.1', modules: '67', napi: '3', nghttp2: '1.34.0', node: '11.6.0', openssl: '1.1.0j', tz: '2018e', unicode: '11.0', uv: '1.24.1', v8: '7.0.276.38-node.13', zlib: '1.2.11' }

[emamulandalib]

I have found another solution. Use Opera's Chrome debugger tool. That tool is compatible with Node v10+.

[lxe]

Canary Version 75.0.3763.0 (Official Build) canary (64-bit) for MacOS seems to work.

[HelmZalee]

This problem (ignoring breaks) has been on again/off again for a couple of years. Right now, I"m using Version 73.0.3683.103 (Official Build) (64-bit). 10 minutes ago, it was working fine; now after editing the source (in an external editor), breakpoints are ignored.

Nowhere in the comments (or documentation) have I seen a reference to what seems to be intended as an indication that a file has been "added to the workspace" (by virtue of its being in the workspace). If a green disk appeared next to the file name ,
I could specify breaks, and the debugger respected them. The difficulty was in getting the !@#$ green disk to show up. Now, however, the green disk appears, I can specify break points...and the debugger ignores them. Resorting to killing/restarting chrome may fix things...

[HelmZalee]

...and stopping/restarting did fix things. The debugger reopened with the same code visible as before. On opening the page to be debugged, the same breakpoints appeared, and the debugger stopped as expected.

[vladimyr]

Currently, https://bugs.chromium.org/p/chromium/issues/detail?id=941608&q=nodeJS

This got resolved in version 74 (details) that went out few days ago: https://chromereleases.googleblog.com/2019/04/stable-channel-update-for-desktop_30.html

[ehmicky]

My original issue is fixed with Chrome 74. I suggest:

• this issue should be closed, unless someone can reproduce the original issue with Chrome 74.
• if there is another breakpoint issue with Chrome 74, please include steps to reproduce.

[jugmablume]

This problem is not fixed in version 74.0.3729.131. Adding the "debugger" statement works.

[bradisbell]

I don't know if this is helpful to anyone, but I finally figured out my problem... symlinks. Depending on the tooling I was using, some tools would resolve symlinks and others wouldn't, making debugger statements "work" because the source would be available, even if technically at a different path.

[targos]

This should be fixed now, at least with Chrome 75

[ajcypherint]

Ugh this is back in 77.

[najibla]

I have the issue in 78

[Trott]

If someone who has details on their setup where it's not working could open a new issue and link to this one, that would be great.

[UtmostCreator]

The same issue with nodejs 13 and 12.13.1 + Chrome v79

[june07]

Reminder that https://blog.june07.com/nim-custom-devtools-url works as a way to utilize previous DevTools versions with 73.0.3683.86... and other combinations as well.

[vineelags]

I have same issue in
Chrome Version 79.0.3945.88 (64-bit)
node version v10.13.0

[juniorjp]

Same issue in Version 78.0.3904.108 (Official Build) (64-bit)

[stevemoncada]

Same thing on 10.17.0 and 13.7.0 with Chromes 79 and 81 (Chromium) in all 4 combinations. debugger statements work fine.

Has anyone come across an explanation of this issue? @HelmZalee 's description of the green disks in Chrome DevTools is the only mention of that indicator that I can find.

[priyavenkat95]

Same issue happend to me.Debug not works, My chrome version is 80.0.3987.100. Can anyone give a solution for my problem.

[MelvBa]

83.0.4103.116 has the same issue. debugging does not work.

[sfnd]

I'm seeing it in 85.0.4183.121

[june07]

Reminder that https://blog.june07.com/nim-custom-devtools-url works as a way to utilize previous DevTools versions with 73.0.3683.86... and other combinations as well.

I'm seeing it in 85.0.4183.121

Working for me...

Screenshot today as of Chrome Version 85.0.4183.121 (Official Build) (64-bit)

More information... https://blog.june07.com/more-than/

[sfnd]

So, it's kinda working. Seems like it has something to do with paths to the source files. I end up with two different views on the same source file: the original is a Windows path "file:///D:/Documents...", the second is a Linux path "file:///home/foo/nodejs/...". The breakpoint I set in the original Windows file does nothing; the second file pops up when the inspector stops at the "debugger;" line and, once it comes up, any breakpoints are obeyed. So I can get work done with this set-up. But it's confusing to have two different views of the same document, both of which seem to accept breakpoints, but only one of which is actually active and valid.

[oxk4r01]

So, is there some way to make breakpoints visible? I'm running Versión 87.0.4280.66 (Build oficial) (32 bits) and only debugger statements are working...