That normalize code should only be executed if the source could not be found - otherwise source should not be null and the rawSource should be passed to the adapter.
Do you know why is that?
As for the normalize(uri.fsPath) 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 process.sources, 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 debug: but the ones in process.sources don't.

I don't know about replacing uri.fsPath, resource.toString(true).substr('debug:'.length) would do it if that isn't too hacky.

Yes, process.sources 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 ce177da adding back the query: '' in DebugContentProvider.getTextContent. @weinand is that needed?

Also, #33712

I think opening the file by putting its url into a debug: 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 #32845.
My suggestion would be to add the ability to open files using the numerical sourceReference that the debug adapter assigned to them or using the Source 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 Source -> uri -> Source preserves the data so that the initial and resulting Source 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:

const sessionId: string = ...
const source: Source = ...

const uri = vscode.Uri.parse(`debug:${encodeURIComponent(source.path)}?session=${encodeURIComponent(sessionId)}&ref=${source.sourceReference}`);

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.

To client: {"seq":0,"type":"event","event":"loadedSource","body":{"reason":"new","source":{"name":"test1.js?blah","path":"http://localhost:8080/out/client%20with%20space/test1.js?blah","sourceReference":1000}}}

From client: source({"sourceReference":1000,"source":{"path":"http://localhost:8080/out/client%20with%20space/test1.js%3Fblah","sourceReference":1000}})

It is escaping the query parameter, but works anyway

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.