Can you give some more context as to what is going on? Internally DevTools only uses file:// urls, so those should be equivalent.

Sure, so I launch DevTools by using "node --inspect-brk <file.js>"

This loads the file into DevTools correctly (as it is mapped to "/Users/...").

I can then go into DevTools and add a folder which contains additional code I want to be able to step through. However, when those files get added they are mapped to "file:///Users/...". I can set breakpoints in those files, but the debugger never hits them.

If I can manage to get the same file loaded using the "/Users/..." (obviously need to re-create breakpoints) then the debugger properly stops on them.

Make sense?

Just to be clear, the default mapping in DevTools to file:// URLS prevents breakpoints from working in those files.

You should be able to easily reproduce. Launch devtools via "node --inspect-brk <file>". Set a break point in that file.

The load the folder into the navigation tree on the left, open the same file there, and you will see that it opens the same file with a different path, and it lacks the breakpoint.

Unable to reproduce this issue on 66.0.3359.170 on Mac 10.13.3 with steps mentioned below.

1. From terminal launched .js file with node ,(say node --inspect-brk /Users/linuxtechm/Downloads/webext_webRequest_docUrl_attribution_demo/background.js)
2. In chrome navigated to 127.0.0.1:9229 in chrome browser and opened devtools
3. Added folder to workspace -- In workspaces section observed it as file:// URLS only.
4. Now in added folder opened background.js file and set breakpoints -- able to see breakpoints without any fail.

@Reporter: Please check the video and let us know if we miss anything. Is this happening with particular file or all files. Please attach sample file and video in reproducing the issue.

Thanks!

Deleted: 838891.mp4 2.6 MB

	838891.mp4 2.6 MB View Download

Thanks, I appreciate the follow up. And sorry for the confusion, but yes, you can set a breakpoint. But it won't stop on those breakpoints that you set on the files with the file:// mapping. That's what this bug is about.

My comment above (which I think generated confusion) was just trying to demonstrate that the inspector thinks the files are different when the mappings are different. Given the same file, with the two mappings, set a breakpoint in one, and you won't see it in the other. I am not entirely certain that is a reflection of the bug or not.

But to be clear, the issue is that for me breakpoints set in file:// mapped files are ignored.

Thanks!

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Here is a video showing the issue. Notice the two different file mappings for the same file. I show that they show different breakpoints. And it only stops for the breakpoint set in the one mapping.

And what makes this really problematic is that the mapping used when folders are added to the explorer use the mapping that ignores breakpoints...

Deleted: 838891-2.mov 7.6 MB

	838891-2.mov 7.6 MB View Download

Workspaces 2.0 is imperfect and there's no feasible way to make it work for everybody. Archiving since we currently don't have resources to allocate towards improving Workspaces story.