Complete CDP domain proxy system with IPC channels, async communication, RAII memory management, robust conditional compilation support, Log domain implementation, real-time event broadcasting, instance-based communication architecture, singleton client-side logging system, and improved code organization

[Copilot]

This PR implements a complete Chrome DevTools Protocol (CDP) domain proxy system with full IPC-based communication between host and content processes, eliminating simulation code and adding comprehensive async support with modern C++ memory management, robust conditional compilation support, complete Log domain implementation, real-time event broadcasting to DevTools clients, instance-based communication architecture, singleton client-side logging system, and improved code organization through encapsulation.

Key Implementation Features

🔄 Real IPC Communication

• Inspector IPC Channels: Added inspectorCommandChanClient, inspectorCommandChanReceiver, and inspectorCommandChanSender to both TrContentRuntime (host) and TrClientContextPerProcess (content)
• Bidirectional CDP Flow: Host processes send TrCdpRequest commands and receive TrCdpResponse messages via actual IPC channels
• Content Process Integration: Inspector commands are processed in the main content runtime tick loop alongside other IPC channels

⚡ Async Architecture & Real-time Event Broadcasting

• Non-blocking WebSocket Processing: Added processMessageAsync() method that eliminates synchronous waiting for content process responses
• Real-time Event System: Content processes send TrCdpEvent IPC messages that are broadcast to all connected DevTools clients via TrInspector::broadcastEventToClients()
• Instance-based Response Registry: CDP clients operate with responses routed to the correct proxy instance via CdpHandler references
• Event Flow: Content processes → TrCdpEvent IPC → Host process → Broadcast to all CDP clients

🎯 Modern C++ Memory Management & Domain Dispatch

• RAII Compliance: All inspector channels use unique_ptr for automatic memory management, following codebase conventions consistently across host and client processes
• Domain-Based Routing: CDP requests are parsed and dispatched to appropriate domain handlers (Runtime, Example, Log)
• Content CDP Handler Integration: Uses existing ContentCdpHandler infrastructure for proper method extraction and domain-specific processing
• Comprehensive Error Handling: Proper CDP error responses for unknown domains, parsing failures, and initialization errors

🛡️ Robust Conditional Compilation & Shared Components

• TR_ENABLE_INSPECTOR Guards: All inspector features are conditionally compiled using TR_ENABLE_INSPECTOR preprocessor directives for optional inspector support
• Fixed IPC Initialization: Resolved critical issue where unconditional assertions prevented content processes from starting when inspector features were disabled
• Header-Only Shared Classes: Moved CdpMessage, CdpResponse to src/common/inspector/cdp_message.hpp as header-only implementations shared between runtime and client processes
• Clean Architecture: Inspector functionality can be completely disabled at compile time without affecting core functionality

📝 Complete CDP Log Domain Implementation

• Chrome DevTools Protocol Compliance: Implements all Log domain methods: enable, disable, clear, startViolationsReport, stopViolationsReport
• Log Entry Management: Full LogEntry structure supporting source, level, text, timestamp, and optional metadata (URL, line numbers, stack traces)
• Real-time Log Events: Automatic Log.entryAdded event broadcasting when entries are added or domain is enabled
• Performance Violations: Configurable violation types including longTask, longLayout, blockedEvent, blockedParser, etc.

🔧 Singleton Client-side Logging System

• Global Logger Access: logging::Logger::GetInstance() provides singleton access throughout the application
• DevTools Integration: Logger automatically sends messages to ContentCdpLogDomain for real-time DevTools visibility
• Convenience Functions: Global functions like LogInfo(), LogJsError() for easy application logging
• Fallback Support: When CDP is disabled, falls back to std::cout/std::cerr output

🏗️ Improved Code Organization & Encapsulation

• ContentInspector Class: Encapsulated all client-side inspector functionality (IPC channels, CDP handler, worker threads) into a dedicated class, removing scattered fields from TrClientContextPerProcess
• RuntimeContentInspector Class: Encapsulated all runtime-side inspector functionality into a dedicated class, simplifying TrContentRuntime
• Common Domain Configuration: Centralized domain configuration in src/common/inspector/cdp_domains.hpp for consistent use across runtime and client processes
• Unified Constructor Pattern: Merged ContentCdpHandler constructors into single constructor with optional parameter
• Clean Include Structure: Reordered includes following standard library first, then project includes pattern throughout codebase
• Removed Debug Clutter: Eliminated excessive debug logging for cleaner production code

Technical Architecture

The system implements a complete multi-process CDP communication architecture with clean separation of concerns:

1. Host Process: Manages WebSocket connections to DevTools clients and forwards requests via IPC
2. Content Processes: Run domain handlers and send responses/events back to host
3. IPC Layer: Uses dedicated inspector channels with TrCdpRequest, TrCdpResponse, and TrCdpEvent messages
4. Event Broadcasting: Real-time events from content processes appear immediately in connected DevTools instances
5. Encapsulated Components: Inspector functionality is properly encapsulated in dedicated classes

Supported Domains

• Runtime: JavaScript runtime inspection (Runtime.enable, Runtime.getVersion)
• Log: Complete CDP Log domain with real-time log entry broadcasting
• MyExample: Testing domain for connectivity verification
• JSAR.UniversalRenderingServer: Host-side renderer debugging and control

DevTools Integration

Applications can now use the singleton logger for immediate DevTools visibility:

#include "client/logger.hpp"

// Singleton access
auto logger = logging::Logger::GetInstance();
logger->jsError("Application error occurred");

// Or convenience functions
logging::LogInfo("Application started");
logging::LogJsWarn("JavaScript warning");

Log entries appear immediately in Chrome DevTools Console with proper categorization, timestamps, and metadata.

Code Quality Improvements

• Encapsulation: Inspector functionality is properly encapsulated in dedicated classes rather than scattered across large classes
• Maintainability: Common configuration and shared utilities reduce code duplication
• Readability: Removed excessive debug logging and improved include organization
• Consistency: Unified constructor patterns and memory management approaches
• Modularity: Inspector features can be completely disabled at compile time without affecting core functionality

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[yorkie]

@copilot Please finish the TODO as you described, but you need to introduce an async method to respond to client.

[Copilot]

I've implemented the async CDP forwarding system as requested. The new implementation includes:

1. Async method: Added forwardRequestAsync() with callback support
2. Timeout handling: 30-second timeout with proper cleanup
3. Enhanced tracking: PendingRequest struct now supports both sync and async flows
4. Error handling: Comprehensive error responses for failed requests

The synchronous forwardRequest() method now internally uses the async version with a condition variable for backward compatibility. The system is ready for full IPC integration when inspector channels are added to TrContentRuntime.

Commit: 3059b13

[yorkie]

Please implement this or you can call to the ContentManager directly.

[Copilot]

I've implemented proper content runtime lookup using the ContentManager as suggested. The new findContentRuntime() method:

1. Uses ContentManager: Calls constellation_->contentManager->getContent() to find content runtimes
2. Validates client ID: Converts clientId to content ID with proper error handling
3. Checks availability: Verifies the content process is running and not being destroyed
4. Comprehensive logging: Added debug logs for troubleshooting

The implementation now properly integrates with the TrConstellation/ContentManager architecture instead of returning null.

Commit: 3059b13

[yorkie]

@copilot add the ipc channels related code to implement send request to client/inspector and respond reversely.

[yorkie]

@copilot Implement this TODO

[Copilot]

I've implemented the TODO at line 144. The sendCdpRequestToContent method now:

1. Creates a real TrCdpRequest command with the CDP message JSON
2. Sends it to the content process via the inspector IPC channel using contentRuntime->sendInspectorCommand()
3. Handles errors properly if the IPC send fails
4. Removed all simulation logic

The content processes receive these requests and respond with TrCdpResponse messages that are routed back to the correct proxy instance.

Commit: adc9fff

[Copilot]

@copilot add the ipc channels related code to implement send request to client/inspector and respond reversely.

I've implemented the IPC channels related code for CDP communication between host and content processes. The implementation includes:

1. Inspector IPC channels in TrContentRuntime: Added inspectorCommandChanClient, inspectorCommandChanReceiver, and inspectorCommandChanSender with proper connection handling
2. Actual CDP request sending: Replaced simulation in sendCdpRequestToContent with real TrCdpRequest IPC communication
3. Reverse response handling: Content processes send TrCdpResponse back to host via inspector channels, using a static registry system to route responses to the correct proxy instance

The system now supports full bidirectional CDP communication with async forwarding and proper content process lookup.

Commit: adc9fff

[yorkie]

@copilot You also need to create inspector channel receiver and sender at content process(TrClientContextPerProcess), and initialize a WorkerThread for processing the incoming inspector requests.

[Copilot]

@copilot You also need to create inspector channel receiver and sender at content process(TrClientContextPerProcess), and initialize a WorkerThread for processing the incoming inspector requests.

I've implemented the inspector channel receiver and sender at the content process (TrClientContextPerProcess) with a WorkerThread for processing incoming inspector requests.

The implementation includes:

Content Process Side (TrClientContextPerProcess):

1. Inspector IPC channels: Added inspectorChanClient, inspectorChanSender, and inspectorChanReceiver fields
2. Worker thread: Created inspectorCommandWorker that processes incoming CDP requests
3. CDP request handling: Added onInspectorCommand() method that receives TrCdpRequest and sends back TrCdpResponse
4. Channel initialization: Inspector channels connect using inspectorChanPort during client startup

Host Process Side:

1. Inspector command server: Added inspectorCommandChanServer to TrInspector for accepting connections
2. Content manager integration: Added inspector command channel watcher and client connection handling
3. Hive daemon configuration: Added inspectorChanPort to daemon configuration passed to content processes

Full Communication Flow:

• Host → Content: CDP requests via TrCdpRequest IPC messages
• Content → Host: CDP responses via TrCdpResponse IPC messages processed by the existing ContentDomainProxy::handleResponseFromContent() method

The content processes now receive CDP requests asynchronously in their main tick loop and respond with appropriate CDP responses back to the host process.

Commit: 6f4d12e

[yorkie]

@copilot Update for my reviews.

[Copilot]

Pull Request Overview

This PR implements a comprehensive Chrome DevTools Protocol (CDP) domain proxy system that transforms the JSAR Runtime inspector from a simulation-based system to a real IPC-based communication architecture. The implementation adds bidirectional CDP communication between host and content processes, real-time event broadcasting, modern C++ memory management, and conditional compilation support.

Key changes include:

• Complete IPC-based CDP communication replacing simulation code with actual inter-process messaging
• Real-time event broadcasting system that sends CDP events from content processes to all connected DevTools clients
• Comprehensive Log domain implementation with singleton client-side logging system for automatic DevTools integration

Reviewed Changes

Copilot reviewed 38 out of 38 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/runtime/inspector/*.{hpp,cpp}	Host-side inspector architecture with IPC channels, content domain proxy, and async CDP processing
src/common/inspector/*.hpp	Shared IPC message structures and CDP utilities for communication between processes
src/client/inspector/*.{hpp,cpp}	Content-side inspector implementation with domain handlers and real-time event broadcasting
src/client/logger.{hpp,cpp}	Singleton logging system with automatic CDP Log domain integration
src/runtime/{content,content_manager,hive_daemon}.{hpp,cpp}	Inspector IPC channel integration and conditional compilation support
docs/internals/CDP_SUPPORT.md	Comprehensive documentation of the new CDP system architecture