Threading and communication between QuickJS and Webview (V8 JS Engine)

[gregvolny]

Early this year, I faced a wall when trying to implement basic offline map routing (gregvolny/CSPro-Demos#7) efficiently in CSPro's QuickJS worker thread engine....

Response from GPT-5.2-Codex (used last January)

The QuickJS context is created with JS_NewContext, and only print, console, and the CS Action Invoker are added. There are no calls to js_std, js_os, JS_AddIntrinsicOS, or any Worker registration.
See Executor.cpp:1-75.
There is no Worker API or os.Worker exposure in zJavaScript. The “worker” functions in Executor.cpp are internal helpers for wrapping module functions (e.g., ExecuteFunctionWorker), not thread workers.
See Executor.cpp:695-755.
QuickJSAccess only handles context/runtime setup, module loading, and error handling. No Worker hooks.
See QuickJSAccess.h and QuickJSAccess.cpp:1-200.
Conclusion: CSPro’s current zJavaScript integration does not provide complete QuickJS support for Workers (os.Worker), so Worker-based multithreading is not available without additional native integration.

I used a workaround running some codes in the Webview's QSF worker thread and partly solve the issue. However, This "background webview" is only available for items having QSF, not for other form components such as level, etc.

Thanks to powerful LLMs, I implemented low level technical report to understand how QuickJS and Webview (V8 JS Engine) can communicate and I'm sharing them with you.
As I mentioned to @Oryxamus, implementing event loop (or other appropriate technologies) in CSPro logic or QuickJS NG can facilitate expanding

CS.getWindowForEventListener().addEventListener("message", event => {
    // ...
});

where a "Window" environment simply don't exist such as in CSPro logic and QuickJS.

---

CSPro 8.1 — QuickJS ↔ WebView JavaScript Communication Report

Date: Jan 2026 (Updated: April 2026)
Scope: Analysis of how JavaScript executed in QuickJS-NG and JavaScript running in WebView2 (Chromium) communicate within CSPro 8.1's architecture
Source: cspro-dev 8.1 codebase

---

Executive Summary

CSPro 8.1 embeds two distinct JavaScript engines: QuickJS-NG (a lightweight C-based engine for CSPro Logic scripting) and WebView2/WebView (the Chromium-based rendering engine for HTML dialogs, views, Question text and can also be used to run JS ). These two engines do not communicate directly with each other. Instead, both route through a shared C++ ActionInvoker::Runtime instance — the central dispatch hub that processes all Action Invoker requests regardless of origin.

WebView/WebView2 has two JavaScript APIs: the new CSProActionInvoker class (full Action Invoker wrapper with all 16 namespaces, loaded from action-invoker.js) and the legacy CSPro class (deprecated since 8.0, injected via AddScriptToExecuteOnDocumentCreated(), will be removed). The legacy CSPro.runLogic() method still exists but wraps Logic.eval — new projects should use CSProActionInvoker.

There is no dedicated "JS" or "JavaScript" namespace in the Action Invoker. The 16 namespaces are: Application, Clipboard, Data, Dictionary, File, Hash, Localhost, Logic, Message, Network, Path, Settings, Sqlite, Sync, System, and UI — plus 3 global actions (execute, registerAccessToken, throwException). The Logic namespace serves as the primary cross-engine bridge, enabling both engines to (evaluate CSPro Logic expressions in the future), invoke functions, and read/write symbol values through the shared interpreter state.

Table of Contents

1. Architecture Overview
2. The Two JavaScript Engines
3. Action Invoker Namespaces — No "JS" Namespace
4. QuickJS → C++ Communication Path
5. WebView2 → C++ Communication Path
6. C++ → WebView2 Communication Path
7. The Logic Namespace as a Cross-Engine Bridge
   • 7.1 Critical Limitation of Logic.eval
   • 7.2 Workaround: Wrap Built-in Logic in User-Defined Functions
   • 7.3 Logic.invoke — The Alternative
   • 7.4 Cross-Engine Communication Example
8. Shared ActionInvoker::Runtime — The Hub
9. Synchronous vs. Asynchronous Patterns
10. Security: Access Token Model
11. Sequence Diagrams
12. Key Source Files
13. Practical Implications
14. Conclusion

---

The full report can be read here:

CSPro_QuickJS_WebView_JS_Communication_Report.md

PS: I also implemented a report about direct communication pathways between these two JS engines in the CSPro ecosystem. I will share it very soon.

[gregvolny]

Continuing thinking about event loop, receiving worker messages directly in CSPro logic, I'm reading about existing CSPro logic global functions such as OnStop, OnKey, OnSyncMessage event handlers. So, it will not be too difficult to implement an "OnMessage" global function in CSPro logic. The UI.postWebMessage Action would be UI.postMessage Action or simply removing it from the UI namespace and integrate it in a new Threading namespace regrouping postMessage and all the new actions from the document "QuickJS_Worker_WebView2_V8_Communication_Report".