Extra slashes in URL can cause breakpoints to not be bound

[EricCornelson]

Repro:

1. set a breakpoint in any js/ts file
2. launch the browser (but to a different url)
3. navigate to the url which loads the script with the breakpoint, but add an extra slash (e.g. http://localhost:5000//index.html)
4. the URL in the scriptParsed event will have the double slash, and the URL Regex on the breakpoint set will not match

If you unset and re-set the breakpoint after navigating to the url with the double slash, the breakpoint will be bound and hit properly.

We noticed this in one of our tests which happened to have a double slash in the URL by accident, and was passing on V1, but failing on V3.

logs: vscode-chrome-debug.txt

[connor4312]

Looking at the URI spec, they make no special stipulation about multiple slashes, they're sent to the server. They can be equivalent to a single slash, or they can not be, it's up to the server to decide. I don't think js-debug should make an assumption. If the user needs multiple slashes, they should be able to add a pathMapping for that.

[EricCornelson]

Normally I'd agree, but since it's a regression from V1 behavior I'd err on the side of allowing it.

The issue is mainly in the case of accidental multiple slashes. Most web servers will serve up the correct page even if you have erroneous extra slashes, and so the user will see the correct page loaded in the browser, but debugging is now broken for them with no hint as to why, no error messages, just unbound breakpoints.

IMO we should be at least as tolerant to these kinds of inputs as browser and web servers are, otherwise debugging starts breaking for all sorts of reasons that are very hard to diagnose for users.

[connor4312]

This doesn't work on the old debugger either for me. What I tried:

1. Using web-worker demo https://github.com/microsoft/vscode-js-debug/tree/master/demos/web-worker modify the launch config to

{
  "type": "chrome", // or pwa-chrome for js-debug
  "request": "launch",
  "name": "[web-worker] launch with server",
  "urlFilter": "*",
},

2. Use http-server to serve assets, since serve doesn't support double slashes in paths https://www.npmjs.com/package/http-server

3. Launch the browser, then navigate to http://localhost:5000//index.html

4. Breakpoints in main.js aren't bound on either the old or the new debugger

[EricCornelson]

I'm able to hit breakpoints in a dotnet web app (on V1). Repro project: https://github.com/EricCornelson/repro_double_slash_bug

[connor4312]

I can repro there.

It doesn't look like v1 sets the breakpoints until the scriptParsed event comes in, whereas we set them ahead of time. There are two solutions:

1. Make the url regex accept any amount of slashes in the url, replace / with \/+ rather than just \/. This would work, not sure about side-effects though...
2. Add some code at runtime that updates the breakpoint URL. This would be a novel mechanism (for scripts without sourcemaps). I dislike adding the complexity-convenience tradeoff here.

[connor4312]

We haven't had any reports of people running into this or 👍's on this issue since js-debug became the default. Do you think this is something we should still look at? Do you happen to collect any data to see how many people in VS hit this?

[EricCornelson]

I'd still argue we should address it, because like I noted in my earlier reply, it's not something that users will easily catch, their breakpoints will just stop working if they have a typo in their URL (even though the page will usually be served just fine) and they'll attribute that to "general flakiness" in the debugger.

While we don't have any data on this specific case, breakpoints not binding correctly tends to be one of our largest "buckets" in terms of debugger feedback, and, for our customers' sake, I'd rather not increase the number of ways that can happen if we can help it (especially when, again, there's no easy way for a user to diagnose why their breakpoints aren't binding in this case).

[connor4312]

The default webRoot is your workspace folder. Please open a new issue if something's going wrong.