Breakpoint jumps due to line breaks

[corey-aloia]

• VSCode Version: May 2018 (version 1.24)
• OS Version: macOs High Sierra 10.13.4

Steps to Reproduce:

1. Using node + jest, have a line with a break similar to:

expect(my.function.with.long.path)
      .toHaveBeenCalledWith(param1, param2, param3, param4);

2. set a breakpoint somewhere after this line
3. observe that when starting in debug mode, the breakpoint will jump n lines, where n is the number of line breaks before said breakpoint. In this example, it will jump 1 line.
4. remove line break. I.E.

expect(my.function.with.long.path).toHaveBeenCalledWith(param1, param2, param3, param4);

5. observe that the breakpoint will no longer jump.

I have tested the above multiple times on 2 different macs, and you can count the line breaks and predict where the breakpoint will jump to. When I say jump, the actual line number for the breakpoint will increase. I.E. a breakpoint at myfile:37 will increase every time you click on debug by the amount of line breaks present in the file before the breakpoint.

Let me know if anymore information is needed!

Here is my launch config:

{
    "version": "0.2.0",
    "configurations": [
      {
        "name": "Debug Jest Tests",
        "type": "node",
        "request": "launch",
        "program": "${workspaceFolder}/node_modules/.bin/jest",
        "args": ["--runInBand"],
        "console": "integratedTerminal",
        "internalConsoleOptions": "neverOpen"
      }
]
}

There is no Babel or Typescript.

Vs Code is awesome by the way!

Regards,
Corey

Does this issue occur when all extensions are disabled?: Yes

[roblourens]

I can't repro this in a Jest project I have. Can you share your project? Are you sure that there are no sourcemaps or transpilation step involved?

Have you debugged this with Chrome devtools?

[corey-aloia]

Hi @roblourens, thanks for the quick feedback. I went ahead and created a dummy project to demo:
https://github.com/corey-aloia-sap/vscode-bug
if you set a breakpoint in the spec.js on line 9, you should see that after clicking the green play button in the debugger, the breakpoint will move to line 10. Let me know if you need anything else!

Regards,
Corey

[krvikash35]

@corey-aloia-sap I also had this issue but it got resolved when i put "sourceMaps": false, in configuration. Just try and see if it helps you.

[corey-aloia]

@sysleaf yes, this stops it from jumping, thanks! I had been removing the line breaks, but knowing this is super helpful!

[roblourens]

I really thought I replied to this already, but I guess not, sorry. I tried the test project earlier and saw that the file at runtime was transpiled or transformed and linebreaks were removed. Sourcemaps should cover this but they were incorrect or missing.

[corey-aloia]

@roblourens I just had a look at the vscode documentation, and it sounds like in this case the breakpoints should be showing up as gray and not hitting, but in my case they are red:

If no source map exists for the original source or if the source map is broken and cannot successfully map between the source and the generated JavaScript, then breakpoints show up as unverified (gray hollow circles)

Or am I misinterpreting this?

Thanks!

[roblourens]

On second thought, this is a bug. There's still something wrong with this case when the generated file has the same name as the source file.

[corey-aloia]

@roblourens setting sourceMaps to false did not fully resolve this as I had initially said. Instead, it lead to it jumping under other scenarios. I.E. it fixed the one test case I presented in my demo project, but I have since run into more. I have added two more demo scenarios that can be viewed in the readme. Maybe this is a problem with the way Node is interacting with files that have line breaks and empty spaces. Either way, something doesn't seem right.

Thanks again!

[roblourens]

I wouldn't expect that to fix it. That option just tells the adapter to ignore the sourcemaps which is definitely not the right thing to do.

[roblourens]

Merging this into #60187 as I believe it's the same bug