Change:
return TPromise.wrapError(localize('unable', "Unable to resolve the resource without a debug session")); } const source = process.sources.get(resource.toString()); <del> const rawSource = source ? source.raw : { path: paths.normalize(resource.fsPath, true) }; </del> <ins> let rawSource: DebugProtocol.Source; if (source) { rawSource = source.raw; } else { // Remove debug: scheme rawSource = { path: resource.with({ scheme: '' }).toString(true) }; } </ins> return process.session.source({ sourceReference: source ? source.reference : undefined, source: rawSource }).then(response => { const mime = response.body.mimeType || guessMimeTypes(resource.toString())[0];

Discussion:
Chrome-debug supports .js files with query parameters (). But if I load one with "Open loaded scripts", the query parameter is stripped. This happens here: since fsPath doesn't include the query parameter. Any idea how to make this work? I don't think URI is expecting to have a URL with another scheme.
That normalize code should only be executed if the source could not be found - otherwise should not be and the should be passed to the adapter. Do you know why is that? As for the call - I am not married to it and we can change it to whatever uri massaging techinique would work for you and not break the existing behavior. If we change this I would prefer to be in debt week -april
It tries to get the source from , but it looks like that is only populated when it breaks in there, right? Plus it's a different format, the script from the quickopen starts with but the ones in don't.
I don't know about replacing , would do it if that isn't too hacky.
Yes, is only populated once there is a call stack that contains that source - so if it breaks. Yeah that feels like a total hack. Why don't you experiment with different solutions and create a PR where we can comment and try out different approaches if needed?
This regressed from adding back the in DebugContentProvider.getTextContent. is that needed?
Also,
I think opening the file by putting its url into a uri is very fragile, to say the least. I have listed some problems I've noticed while implementing a Loaded Scripts Explorer for the Firefox debug adapter in . My suggestion would be to add the ability to open files using the numerical that the debug adapter assigned to them or using the object that is used for identifying the file in the messages between VS Code and the DA. Whatever solution you adopt, keep in mind that VS Code should be able to determine that the file opened by clicking on a stackframe and the file opened by clicking in the Loaded Scripts Explorer are one and the same - otherwise setting breakpoints in a file opened through the Loaded Scripts Explorer will become problematic.
I've addressed this issue by making sure that the flow -uri -preserves the data so that the initial and resulting objects are identical. The "path" attribute of the source object can contain anything, e.g. a file system path or a full URL.

So if a Uri is constructed in the following way: the debugContentProvider inside VS Code will retrieve the content by sending a "sourceRequest" with a "Source" argument to the debug adapter identified by the debug session.
Verify that Rob's Chrome-debug case from above works.
It is escaping the query parameter, but works anyway using the new loadedSources API, because then we can rely on sourceReference instead of a string path.
I have also seen this (with the Firefox debug adapter) and couldn't find any user-visibile ill effects. In particular, the source url is displayed correctly in the tab opened from the Loaded Scripts Explorer (i.e. the query parameter is unescaped there and other escaped characters in the url remain escaped).
Added "Verified" label since both comments from above confirm that this works correctly now.
It does rely on me updating chrome-debug, in case anybody else tries this. I'll do that this week.