Helps to understand the execution flow.

[Jithil P Ponnan]

As I delve into the execution flow of the dev tool console to v8, I'm keen to understand which v8 function is being executed when we enter a line of code in the console panel.

I found the invoke_evaluate is making those interactions. However, the changes were not reflected once I made the changes to the evaluate function in v8 and recompiled the complete chromium.

So, some guidance on correctly identifying the corresponding v8 function and testing them on dev tools would unblock me on the first contribution.

TL;DR- Where can I find the v8 function of invoke_evaluate(params: Protocol.Runtime.EvaluateRequest)?

If we have any design docs of dev tool, that would helps me. 

[Jeremy Roman]

I believe it goes to V8RuntimeAgentImpl::evaluate, which calls v8::debug::EvaluateGlobal (and so on).

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/59a03389-9b83-46fd-a885-b0f89f7f15een%40chromium.org.

[Simon Zünd]

Jeremy is exactly right. The entrypoint from Chrome DevTools Protocol (CDP) into V8 is in the V8RuntimeAgent::evaluate. It does some bookkeeping like setting up a timeout or installing some custom then/catch handlers if the eval result is a promise. The entry point in V8 itself is indeed DebugEvaluate::Global. Keep in mind that the DevTools console uses a special execution mode of V8 that we coined "REPL" mode (bit.ly/v8-repl-mode). It allows let/const re-declaration and top-level await, which is normally not available in classic scripts.

Please note that if the page is paused, then we use a different pair: Debugger.evaluateOnCallFrame (CDP) and the corresponding DebugEvaluate::Local on the V8 side.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACuR13feRrwwTFY0Vwg7CzB7WADF4A_jwQGjYhZ9EOozo7MRKQ%40mail.gmail.com.

[Jithil P Ponnan]

Well said. Thank you so much for the deep knowledge share. From here, I would be able to triage the issues further and raise a PR. 

This discussion can be closed. 

On Tue, 27 Aug 2024 at 21:25, Simon Zünd <szu...@chromium.org> wrote:

The backend (Chromium, V8) and the DevTools frontend talk via the Chrome DevTools Protocol (CDP) https://chromedevtools.github.io/devtools-protocol/ with each other. There are multiple possible transport channels, but the most important are WebSockets and host bindings.

If you use DevTools "the standard way", by pressing F12 or "Right click -> Inspect". You use the host bindings. In that case Chromium creates a special DevToolsWindow. It's basically a normal browser tab but with a special "DevToolsHost" object installed. This allows the frontend to call JavaScript methods that are then handled in the backend in C++. CDP itself is also routed by basically calling `DevToolsHost.sendMessageToEmbedder({ method: 'dispatchProtocolMessage': ....});`. This is handled in devtools_ui_bindings.cc. From there, each CDP command invocation makes it's way through the various layers in Chrome:

1. First we arrive chrome/browser/devtools, if the command is not handled here we fall through to content/
2. If content/browser/devtools doesn't wants to handle the CDP command we fall through to blink
3. If third_party/blink/renderer/core/inspector doesn't want to handle the CDP command we fall through to V8
4. v8/src/inspector should now handle the CDP command.

Just to point out, if you are only interested in changing the behavior of Runtime.evaluate, you don't need to know any of this.

On Tue, Aug 27, 2024 at 1:04 PM Jithil P Ponnan <jith...@gmail.com> wrote:

Thank you so much Simon and Jeremy for the clarifications. Seems its unblocking me on the challenge I am facing.

I would like to get some more details about, what happens once a user types an expression in the devtool console and hit enter key. How the expression reaches ` V8RuntimeAgent::evaluate`. There must be some bridge which will invoke the corresponding c++ code from ts files.

I am going deeper to find it. However, if you could provide some helping hands here, it will save a lot of effort and would be appreciated so much. 

[Jithil P Ponnan]

Thank you so much Simon and Jeremy for the clarifications. Seems its unblocking me on the challenge I am facing.

I would like to get some more details about, what happens once a user types an expression in the devtool console and hit enter key. How the expression reaches ` V8RuntimeAgent::evaluate`. There must be some bridge which will invoke the corresponding c++ code from ts files.

I am going deeper to find it. However, if you could provide some helping hands here, it will save a lot of effort and would be appreciated so much. 

On Saturday, August 24, 2024 at 7:46:42 AM UTC+10 Simon Zünd wrote:

[Simon Zünd]

The backend (Chromium, V8) and the DevTools frontend talk via the Chrome DevTools Protocol (CDP) https://chromedevtools.github.io/devtools-protocol/ with each other. There are multiple possible transport channels, but the most important are WebSockets and host bindings.

If you use DevTools "the standard way", by pressing F12 or "Right click -> Inspect". You use the host bindings. In that case Chromium creates a special DevToolsWindow. It's basically a normal browser tab but with a special "DevToolsHost" object installed. This allows the frontend to call JavaScript methods that are then handled in the backend in C++. CDP itself is also routed by basically calling `DevToolsHost.sendMessageToEmbedder({ method: 'dispatchProtocolMessage': ....});`. This is handled in devtools_ui_bindings.cc. From there, each CDP command invocation makes it's way through the various layers in Chrome:

1. First we arrive chrome/browser/devtools, if the command is not handled here we fall through to content/
2. If content/browser/devtools doesn't wants to handle the CDP command we fall through to blink
3. If third_party/blink/renderer/core/inspector doesn't want to handle the CDP command we fall through to V8
4. v8/src/inspector should now handle the CDP command.

Just to point out, if you are only interested in changing the behavior of Runtime.evaluate, you don't need to know any of this.

[Jithil P Ponnan]

Well said. Thank you so much for the deep knowledge share. From here, I would be able to triage the issues further and raise a PR.