Clearscript: Document name limitation

[ipjohnson]

I'm running into a limitation with the way document name is implemented with the V8ScriptEngine. Currently if I pass in a document name with path it get's trimmed down to just the filename. This causes a problem as the document name is returned back through the debugging api as just the filename no path.

Could this behavior be changed or possibly overriden?

[ClearScriptLib]

Hi @ipjohnson,

We can confirm that ClearScript currently expects the document name associated with a script to be just a file name, and that it strips away any specified path. Can you clarify what problem this behavior is causing for you?

Thanks!

[ipjohnson]

@ClearScriptLib This algorithm strips the path way which causes two problems

1) When loading files of the same name but in different paths the current algorithm sees them as the same file and creates a count for the second document when they are not.

pathA\file.js
pathB\file.js

2) Just as important I actually want the path maintained so that when V8 returns back the document name through the debugging API (Document name is returned in URL) I can match on it.

I'm sure you don't want to introduce a breaking change to the default behavior but maybe if you could add a way to provide an implementation of IUniqueNameManager that could do it.

[ClearScriptLib]

Hi @ipjohnson,

Just to be sure we're on the same page, when you say "debugging API", what exactly do you mean? Does your application interact directly with the HTTP/WebSocket server that ClearScript establishes for V8 Inspector connections?

Thanks!

[ipjohnson]

Hi @ClearScriptLib

Sorry for the confusion yes you are correct I'm calling the HTTP/WebSocket server to use inspectors. I don't have the specific event I'm listening to on hand but essentially it's fired every time a script is parsed, included is a field called URL that ultimately is the document name.

At the moment I've made a slight change to the current implementation and recompiled it to pass the full name through. While this works I'd rather not have to make changes to the source and recompile just to override this behavior.

[ClearScriptLib]

@ipjohnson We'll look into this issue. Thanks for reporting it!

[ClearScriptLib]

Version 5.5.3 has been posted. It includes new APIs that preserve document path names and expose them to the debugger.

Here's an example:

C# var code = File.ReadAllText(filePath); var result = engine.Evaluate(new DocumentInfo(new Uri(filePath)), code);

Good luck!

[JohnLudlow]

Hi

I think there might be a small issue with path resolution being case sensitive. I was looking at the ClearScriptConsole test app which looks for Startup.js in the same folder. I put startup.js with some simple code in the same folder, and didn't get the expected breakpoint behaviour.

If I changed the test app code to look for startup.js (all lower case) then it worked.

I think somewhere when the document names are compared to see if a file is loaded, it's not doing a case insensitive comparison on systems with case insensitive file systems.

The workaround then is to pass the path with the correct case as it exists on the file system when you create a DocumentInfo.

[ClearScriptLib]

Hi @JohnLudlow,

Neither ClearScript nor the underlying script engine verifies a script's URI; it just provides it to the debugger unaltered (barring absolutization or normalization if necessary).

If the debugger can't associate the URI correctly with a file open in its editor, ClearScript can't do anything about it, unfortunately.

Which debugger are you using, by the way?

Thanks!

[JohnLudlow]

@ClearScriptLib I'm using VS Code to debug (works fine with the right magical settings), though I was also looking at Chrome dev tools as well (which I can't get working).

So I guess we just have to query the file system to get the right casing before passing to DocumentInfo to get the right casing.

Basically, I was looking at the console app included in the repo, and it looks for Startup.js in its own folder. I placed a startup.js in the right place and wondered why it wasn't working. Renaming the file fixed things.

Thanks!

[ClearScriptLib]

Thanks for reporting this @JohnLudlow! We'll pass it along to VS Code. In the meantime we've observed that the Chrome debugger has the same issue.