modify code in DevTools

[flat-eric147]

Originally posted by @ClearScriptLib in #260 (comment)

Hello and thank you for your reply! I am not quite sure how you achieved that. I connected to my host through the DevTools (tried both chrome and edge), set a breakpoint and modified the code in DevTools, but as expected the new code is not executed. When the debugger hits the breakpoint again, a different tab opens with the original code. Any specific settings I forgot? I'm also not sure how the eventually modified code can be read back into my host application. The ScriptEngine class dos not appear to have getter methods to retrieve the code in execution.

[flat-eric147]

Small update, I somehow managed to modify the code when the code hit a breakpoint, then I used CTR+S to save and continue, the code was then executed with the modification, but on further breakpoints it did not execute any modifications, it just kept running the first modification.
Said that, I still have no idea on how to retrieve the modified code back into my application. Having this all working properly would be a really powerful feature. But anyhow, have I told you how much I love ClearScript? :-D

[flat-eric147]

Hi, another update after more than 2 years :) In the meantime I was playing with CEF and webView2 but they both have massive disadvantages, for the interested reader her my results:

Using CEF and the ShowDevTools mehod to bring up and use the debugger:

• It seems it is not possible to add workspace with the DevTools opened, see cef forum comment
  Without the workspace you cannot save any js files, meaning that it's pointless to use it in the hosting application. I want the user to be able to edit and save the code in the DevTool transparently.
• In theory one could construct a link like
  devtools://devtools/bundled/inspector.html?ws=localhost:4999/devtools/page/256606BCB8B7F6CA7CFD3ED6989AD45D
  and open that in an external chrome browser (instead of the internal CEF). The problem with this approach is that you can only do this MANUALLY by copying the url by hand to a chrome browser, so there is no way to invoke this from the host application through a process invocation. This must be some "protective feature" in chrome.

Using MS webView2 (invoking CoreWebView2.OpenDevToolsWindow()):

• Can use DevTools and add workspaces
• Needs installation of webView2 package on target machine
• A WebView2 instance needs to be added to visual tree (which can be hidden though)
• CoreWebView2.AddHostObjectToScript accepts only classes that are com visible (eg.[ComVisible(true)]). That makes it difficult/impossible to use certain external class instances within the script.
• Exposed objects can be referenced in JavaScript through a lengthy syntax like
  window.chrome.webview.hostObjects.name instead of just name as in ClearScript.

None of the above approaches suit my needs, although it's intriguing to have a "proper' web browser doing the job opening up new possibilities. So, back to ClearScript. Having now being forced to explore the DevTools in more depth, I figured out something that might solve my original problem sticking to ClearScript. The "magic" can be done by overriding the script content:

• Connect to you ClearScript with chrome inspector (chrome://inspect/#devices), remote debugging in ClearScript must be enabled of course.
• Go to Sources and select Module, right click on it and select Override content.
  
• It will ask you to select a folder, select your folder of choice
  
• Allow full access to the folder
  
• The module should have a violet circle to indicate that it is overwritten
  

Now you can set breakpoints, modify the code, save it with ctrl+s! The modifications will be written to disc of course

Once you stop the script from running in your host application, you can take the script from disc and store it with the modifications made during the debug session. The good thing is that those settings persist over time in chrome, the next time you run the ClearScript and you attach to it, the settings are already in place. You only need to take care of the copy stored on disc, the script will be overwritten by whatever has been found on disc as soon as you attach the debugger. For code consistency, one needs to overwrite the file with the content of whatever you pass to ClearScript BEFORE calling Execute.

I suppose all this works in a similar fashion using Visual Studio Code !?

To make this workflow a bit smoother, it might be useful to have in ClearScript a method "Execute" that takes a file name instead of a string containing the script, but it's easy to workaround this of course. Maybe you have other&better suggestions!

Sorry for the lengthy post, but I feel this might help other users who might stumble about this problem.

[ClearScriptLib]

Hi @flat-eric147,

I suppose all this works in a similar fashion using Visual Studio Code !?

Perhaps not; the content override feature could be unique to DevTools.

it might be useful to have in ClearScript a method "Execute" that takes a file name instead of a string containing the script

Sure, you can do the following:

engine.DocumentSettings.AccessFlags = DocumentAccessFlags.EnableFileLoading;
engine.ExecuteDocument(filePath);

Good luck!

[flat-eric147]

Hi, it's me again. I looked again at this. I managed to execute the script from disc, debug the code in VS Code and reload the mods in my application. So the good new is I can break in the code and see what's happening with VS Code, the bad news is, that the modifications are not updated in the script that executes. You mentioned elsewhere that the debugging communication over websocket between vs code and ClearScript has likely changed over time (and has not been maintained?). Is it likely you look into this for future releases? Thanks!

[ClearScriptLib]

Hi @flat-eric147,

the modifications are not updated in the script that executes

Would you mind expanding on that? It would be helpful to know the exact sequence of steps that's failing for you, along with your expectations.

You mentioned elsewhere that the debugging communication over websocket between vs code and ClearScript has likely changed over time (and has not been maintained?).

A clarification: ClearScript doesn't define or implement V8's debugging protocol. It just provides a communications channel. If the protocol changes, it's possible that a specific ClearScript version – which includes a specific V8 version – no longer works correctly or fully with newer versions of the debugger.

Is it likely you look into this for future releases?

We'll be happy to test your steps with the next release. However, if the root cause is in an external component like V8 or VSCode, the most likely resolution will be for us to submit a bug for that component.

Cheers!

[smokeelow]

@flat-eric147 not sure if that helps, but triggering DocumentLoader.Default.DiscardCachedDocuments(); works for me.

I added watcher for the scripts, and when something changed, i trigger clear cache. Works fine with live debugger session.

[flat-eric147]

Hi!

the modifications are not updated in the script that executes

Would you mind expanding on that? It would be helpful to know the exact sequence of steps that's failing for you, along with your expectations.

Sure. I created a quick and dirty repos that hopefully makes things a bit more clear:
https://github.com/flat-eric147/DebugClearScriptV8

It is a WPF application and it executed the code that is visible in the TextBox. When you click the "DoSomething" button, the Global.DoSomething JS function gets invoked with 1, 2, 3 as arguments. It makes a calculus and calls a Host Object method that adds the result into the log TextBox.

I cannot manage to hook it up to VSCode, modify some code (e.g. make a multiplication instead of a sum) and make ClearScript execute this modified code. I can manage to hook it up to the debugger and somehow step through the code though, that's it.

My settings.json looks something like this:

{
"name": "Attach to Test ClearScript 9224",
"type": "node",
"enableContentValidation": false,
"trace":true,
"request": "attach",
"address": "localhost",
"port": 9224
}

You mentioned elsewhere that the debugging communication over websocket between vs code and ClearScript has likely changed over time (and has not been maintained?).

A clarification: ClearScript doesn't define or implement V8's debugging protocol. It just provides a communications channel. If the protocol changes, it's possible that a specific ClearScript version – which includes a specific V8 version – no longer works correctly or fully with newer versions of the debugger.

Understood. And that's what I believe is the problem.

Is it likely you look into this for future releases?

We'll be happy to test your steps with the next release. However, if the root cause is in an external component like V8 or VSCode, the most likely resolution will be for us to submit a bug for that component.

Please let me know if the above steps are sufficient or if you want me to further expand/report.

Thanks!

[flat-eric147]

@flat-eric147 not sure if that helps, but triggering DocumentLoader.Default.DiscardCachedDocuments(); works for me.

I added watcher for the scripts, and when something changed, i trigger clear cache. Works fine with live debugger session.

Thank's for the hint, tried it and unfortunately it does not work for me.

[ClearScriptLib]

Hi @flat-eric147,

Thanks for sharing your sample code!

I cannot manage to hook it up to VSCode, modify some code (e.g. make a multiplication instead of a sum) and make ClearScript execute this modified code.

It turns out that, unlike DevTools, VSCode doesn't support live editing of loaded scripts. That seems to be a known limitation, possibly rooted in VSCode's file-oriented design, whereas DevTools is more tightly integrated with the JavaScript runtime environment.

Nevertheless, VSCode's debug console fully supports expression evaluation within the attached environment. You can use that capability to replace Global.DoSomething with a different function:

After that, the button handler calls the new function:

Thank's for the hint, tried it and unfortunately it does not work for me.

Discarding the cached documents didn't work because the button handler invokes an existing function instead of executing the document from disk every time. That's usually the right thing to do, at least for performance 👍

Good luck!

[flat-eric147]

Thank you for your kind reply. So a workflows, for a debug/troubleshooting session could maybe look like this:

1. Start Code on a tmp folder where the script executes from file. Somehow launch vscode and tell him to attach to the application
2. break somewhere, perhaps modify the code, SAVE the file (I know vs might complain that it's read only, but I think there are ways around it), and at this point the application watches the file change and then:
3. Reads the updated script content from disc, restarts the clearscript engine (and tell vs code to reattach?)

The question is, I cannot tell ClearScript to reload the script while it executes, right? My only option is to interrupt the execution and start over. I think that's what most frontend developers are used to anyways, right?

Thank you!

[ClearScriptLib]

Hi @flat-eric147,

That workflow seems unnecessarily complicated. The JavaScript environment is fully dynamic. When stopped at a breakpoint, you can change variables, replace global functions, etc.

What VSCode's debugger does not let you do is modify loaded scripts. All that really means is that you can't change the code of existing functions. You can still replace those functions, and there are many ways to do that.

For example, consider the following:

engine.AddHostType(typeof(Console));
engine.DocumentSettings.AccessFlags = DocumentAccessFlags.EnableFileLoading;
engine.Script.reload = new Action<string>(path => {
    engine.DocumentSettings.Loader.DiscardCachedDocuments();
    engine.ExecuteDocument(path);
});
File.WriteAllText("greet.js", @"
    function greet(name) {
        Console.WriteLine(`Hello, ${name}!`);
    }
");
engine.Script.reload("greet.js");
engine.Script.greet("Peter");
engine.Script.greet("Paul");
engine.Script.greet("Mary");

If you run this normally, you'll get this:

Hello, Peter!
Hello, Paul!
Hello, Mary!

But you can also do the following:

1. Attach VSCode and set a breakpoint at the line that calls Console.WriteLine.
2. When stopped at the breakpoint, change "Hello" to "Greetings" and save. VSCode should let you do that – probably because there's a path associated with the script.
3. In VSCode's Debug Console, execute "reload('greet.js')" and continue.

When the program is done, you'll see the following output:

Hello, Peter!
Greetings, Paul!
Greetings, Mary!

Of course, if the script has cached the original function and always calls its cached reference, that won't work. But you can work around that by having the original function delegate its implementation to an easily replaceable one.

Good luck!