Skip to content

Add V8 Inspector/CDP support for Chrome DevTools debugging #7

Description

@wieslawsoltes

Summary

Add first-class V8 Inspector and Chrome DevTools Protocol (CDP) support to WebScene so JavaScript and React code running inside the native V8 engine can be discovered and debugged from Chrome DevTools and compatible IDEs.

Today, WebScene can execute JavaScript, capture V8 stack traces, queue console.log/warn/error output, report unhandled promise rejections, and evaluate code from the managed host. It cannot currently be attached to as a JavaScript debugging target because it does not create a v8_inspector::V8Inspector, expose an Inspector protocol session, host a CDP WebSocket, or publish a discoverable target.

This issue covers the complete path from the embedded V8 isolate to a working chrome://inspect session, including source-mapped breakpoints in original JSX.

Current behavior

WebScene currently provides diagnostic information but not an interactive debugger:

  • synchronous JavaScript failures include a script resource name, generated line number, and V8 stack trace;
  • script compilation uses a meaningful v8::ScriptOrigin document/resource name;
  • console.log, console.warn, and console.error are captured in a bounded native queue, including Error.stack when present;
  • unhandled promise rejections are detected and preserve their stack when available;
  • managed hosts can evaluate JavaScript and receive failures through the native interop path;
  • the Avalonia native view exposes LastError and DrainConsoleMessages();
  • the Uno native view exposes evaluation and render metrics, but does not currently expose equivalent public console/error APIs.

This is enough for logs and post-failure diagnosis, but not for IDE-grade source debugging. In particular, there is currently no support for:

  • Chrome DevTools target discovery;
  • an Inspector/CDP WebSocket connection;
  • Runtime.enable or Debugger.enable backed by the actual WebScene V8 isolate;
  • source-level breakpoints;
  • pause, resume, step into, step over, or step out;
  • paused call frames, scopes, locals, watches, or evaluateOnCallFrame;
  • pause-on-exception;
  • CPU/heap profiling through V8 Inspector;
  • mapping generated bundle locations back to original JSX through source maps.

Using the existing Chrome.DevTools.Protocol server by itself does not solve this. Its Avalonia/Uno Runtime and Debugger domains inspect or simulate the managed application and do not control WebScene's embedded V8 isolate.

Goal

Support the following development workflow:

  1. Launch a WebScene application with an explicit inspector option, for example:

    --webscene-inspect=127.0.0.1:9229
    
  2. Open chrome://inspect/#devices in Chrome.

  3. Configure localhost:9229 as a network target.

  4. See the WebScene document as a discoverable target.

  5. Click Inspect to open Chrome DevTools.

  6. See loaded WebScene JavaScript in Sources.

  7. Set a breakpoint in original JSX using a source map.

  8. Interact with the native Avalonia or Uno application.

  9. Pause inside the real V8 execution context.

  10. Inspect call frames, scopes, local variables, and expressions.

  11. Step and resume without blocking the UI or corrupting the WebScene worker lifecycle.

An optional break-on-start mode should also be supported:

--webscene-inspect-brk=127.0.0.1:9229

Recommended ownership and repository split

The V8 debugger implementation must be owned by WebScene because WebScene owns the V8 isolate, V8 contexts, navigation lifecycle, and native engine worker.

The existing wieslawsoltes/CDP repository can provide reusable HTTP discovery and WebSocket transport, but it must forward Inspector JSON unchanged. It should not reimplement V8 Runtime, Debugger, Profiler, or HeapProfiler semantics in managed code.

Recommended responsibility split:

Responsibility Owner
V8Inspector, Inspector client, sessions, and context groups WebScene native engine
Pause loop, thread affinity, and inbound/outbound inspector queues WebScene native engine
Native inspector ABI WebScene
Managed native-ABI wrapper WebScene
/json discovery and WebSocket transport Lightweight CDP transport
WebScene target registration and transport adapter WebScene integration package
Source-map generation Consuming application/build
React component and hook inspection Separate follow-up

If the CDP repository is not used initially, WebScene may provide a minimal loopback-only discovery/WebSocket server for the first vertical slice. The long-term design should avoid maintaining two independent CDP transports.

Proposed architecture

Chrome DevTools / IDE JavaScript debugger
                ↕ CDP JSON over WebSocket
HTTP discovery + raw CDP transport
                ↕ unchanged protocol messages
WebScene managed inspector adapter
                ↕ native ABI queues and availability signals
WebScene native engine worker
                ↕ V8 thread/isolate/context affinity
v8_inspector::V8Inspector + V8InspectorSession

The native V8 Inspector must remain the source of truth for command responses, notifications, remote-object identifiers, script identifiers, breakpoints, call frames, profiler data, and debugger state.

Required implementation

1. Enable and link V8 Inspector

  • Explicitly build the native runtime with V8 Inspector enabled and verify that the generated Inspector headers and implementation are present in the monolithic V8 artifact.
  • Include v8-inspector.h in the native engine target.
  • Add a focused Inspector implementation rather than expanding the already-large runtime translation unit without separation.
  • Record the actual V8 and Inspector protocol versions in runtime metadata instead of advertising a hard-coded unrelated Chrome/V8 version.

2. Add the native Inspector client

Implement a v8_inspector::V8InspectorClient owned by the V8 isolate.

It must support at least:

  • runMessageLoopOnPause(int contextGroupId);
  • quitMessageLoopOnPause();
  • runIfWaitingForDebugger(int contextGroupId);
  • time/timer callbacks required by the Inspector version used by WebScene;
  • console forwarding where needed;
  • clean shutdown while a session is connected or paused.

Create the v8_inspector::V8Inspector only after the isolate is valid and destroy it before disposing the isolate.

3. Register V8 contexts correctly

  • Assign a stable, non-zero Inspector context-group ID to each WebScene document/runtime.
  • Call contextCreated() for the root context after its embedder data and globals are installed.
  • Register iframe contexts as they are created.
  • Give contexts meaningful names and origins based on the loaded WebScene URL/document.
  • Call contextDestroyed() before resetting each V8 context.
  • Call resetContextGroup() when navigation replaces a document.
  • Ensure navigation cannot leave stale Inspector remote objects or context identifiers behind.

WebScene optionally supports shared isolates. Since V8Inspector is isolate-owned while sessions attach to context groups, shared-isolate mode needs explicit handling:

  • MVP option: inspector mode requires a dedicated isolate and rejects/disables shared-isolate mode with a clear diagnostic;
  • later option: one inspector per shared-isolate shard with distinct context groups and sessions for each WebScene runtime.

The MVP must not silently expose the wrong WebScene document when multiple runtimes share an isolate.

4. Add one Inspector session per debugger connection

Each connected DevTools/IDE client should receive its own V8InspectorSession and channel.

The channel must forward:

  • sendResponse(callId, message);
  • sendNotification(message);
  • flushProtocolNotifications().

Messages must be preserved byte-for-byte as UTF-8 JSON wherever possible. Do not parse and reconstruct V8 protocol payloads in managed code.

Session teardown must call stop()/release the session safely, remove pending messages, and release debugger state without tearing down the WebScene document.

5. Integrate with the engine worker

All calls into V8InspectorSession::dispatchProtocolMessage() must occur with the correct isolate/context/thread ownership.

  • Add a thread-safe inbound Inspector command queue to webscene_engine.
  • Signal the existing engine worker when a command is enqueued.
  • Dispatch commands on the worker while holding the same isolate ownership used by ordinary WebScene execution.
  • Add a bounded outbound response/notification queue per Inspector session.
  • Notify the managed host using a non-blocking “message available” callback; the callback must not call back into the engine.
  • Avoid blocking the Uno/Avalonia UI thread while waiting for Inspector responses.
  • Apply explicit queue limits and disconnect or fail predictably on sustained debugger backpressure.

6. Implement the paused nested loop

When V8 invokes runMessageLoopOnPause(), the WebScene engine worker must enter a nested loop that:

  • remains responsive to Inspector commands;
  • processes Debugger.resume, stepping commands, paused evaluation, property inspection, and object release;
  • does not run ordinary timers, animation frames, input callbacks, React work, or scene publication while JavaScript is paused unless required by Inspector semantics;
  • wakes through a condition variable when a protocol message or shutdown request arrives;
  • exits immediately when quitMessageLoopOnPause() is called;
  • exits cleanly when the engine is disposed or the debugger disconnects;
  • does not deadlock with shared-isolate locks, managed callbacks, navigation, or application shutdown.

This loop is essential: accepting a WebSocket without implementing pause-loop behavior would allow some Runtime commands but would hang on real breakpoints.

7. Add a native Inspector ABI

Add an ABI surface similar to:

typedef void (*webscene_inspector_message_available_callback)(
    void* user_data,
    uint64_t session_id);

WEBSCENE_API uint64_t webscene_engine_inspector_connect(
    webscene_engine* engine,
    webscene_inspector_message_available_callback callback,
    void* user_data,
    uint8_t wait_for_debugger);

WEBSCENE_API uint8_t webscene_engine_inspector_dispatch(
    webscene_engine* engine,
    uint64_t session_id,
    const char* json,
    size_t json_length);

WEBSCENE_API size_t webscene_engine_inspector_take_message(
    webscene_engine* engine,
    uint64_t session_id,
    char* destination,
    size_t capacity);

WEBSCENE_API void webscene_engine_inspector_disconnect(
    webscene_engine* engine,
    uint64_t session_id);

Exact naming and ABI versioning may differ, but the contract must remain asynchronous and worker-safe. Avoid calling managed code with the complete protocol message directly from a paused V8 stack.

Update:

  • the native public header;
  • exported symbol lists for all supported platforms;
  • native runtime manifest/ABI validation;
  • managed P/Invoke declarations;
  • runtime package smoke tests;
  • ABI compatibility tests.

8. Add managed Inspector wrappers

Expose a managed session abstraction in the native backend, for example:

public interface INativeWebSceneInspectorSession : IAsyncDisposable
{
    ulong Id { get; }
    ValueTask DispatchAsync(ReadOnlyMemory<byte> message, CancellationToken cancellationToken = default);
    IAsyncEnumerable<ReadOnlyMemory<byte>> ReadMessagesAsync(CancellationToken cancellationToken = default);
}

The managed wrapper must:

  • own the native session lifetime;
  • copy or lease native message buffers safely;
  • drain outbound messages when signaled;
  • propagate engine disposal and debugger disconnect;
  • avoid marshaling Inspector work through the UI dispatcher;
  • expose current target metadata such as title, URL, V8 version, and target ID.

Also bring the Uno diagnostics surface to parity by exposing public console and last-error access, even though Inspector will become the preferred interactive diagnostics path.

9. Add raw CDP transport support

Chrome expects the standard discovery endpoints:

GET /json/version
GET /json
GET /json/list
WS  /devtools/page/{targetId}

/json/list should return at least:

[
  {
    "description": "WebScene V8 document",
    "id": "<stable-target-id>",
    "title": "<document title>",
    "type": "page",
    "url": "<document URL>",
    "devtoolsFrontendUrl": "devtools://devtools/bundled/inspector.html?ws=127.0.0.1:9229/devtools/page/<target-id>",
    "webSocketDebuggerUrl": "ws://127.0.0.1:9229/devtools/page/<target-id>"
  }
]

The wieslawsoltes/CDP repository already has discovery and WebSocket server code, but its current concrete session parses commands and dispatches them into managed domain handlers. Add a raw/pass-through session contract, such as an ICdpConnectionSession or IRawCdpTargetSession, so a WebScene target can:

  • accept raw WebSocket text messages;
  • forward them unchanged to the native Inspector session;
  • send raw V8 responses and notifications unchanged;
  • bypass CdpDispatcher for V8-owned domains;
  • support asynchronous notifications that are not paired with an incoming command.

Do not register replacement managed handlers for V8 Runtime, Debugger, Console, Profiler, or HeapProfiler domains.

The current Chrome.DevTools.Protocol package includes unrelated dependencies such as Jint, SkiaSharp, profiling libraries, and XAML tooling. Prefer extracting a lightweight transport/discovery package rather than adding that full dependency graph to WebScene runtime packages.

10. Forward console and exception information to Inspector

WebScene currently implements a custom JavaScript console. Continue supporting the existing host console queue, but also send Inspector-compatible console messages so the DevTools Console panel receives them.

  • Forward log level, message, context ID, URL, line, column, and a captured stack where available.
  • Preserve Error.stack for logged error objects.
  • Report synchronous uncaught exceptions through Inspector exception instrumentation.
  • Report unhandled promise rejections and revoke them if a handler is attached later.
  • Avoid duplicate console entries if both WebScene's queue and Inspector instrumentation observe the same call.

11. Preserve useful script identities

WebScene already supplies a v8::ScriptOrigin using the resource/document name. Preserve and strengthen this behavior:

  • use canonical document/resource URLs for external scripts;
  • give deterministic URLs to inline scripts;
  • preserve sourceURL and sourceMappingURL directives;
  • ensure cached compilation retains the same origin metadata;
  • ensure navigation and iframe scripts appear as distinct DevTools sources;
  • verify Debugger.scriptParsed contains stable URLs suitable for setBreakpointByUrl.

12. Enable source-mapped original-source debugging

V8 Inspector can debug generated JavaScript without source maps, but original React/JSX debugging requires the consuming build to emit them.

Update the 7GUIs validation sample from:

sourcemap: false

to an appropriate development configuration such as:

sourcemap: true,
sourcesContent: true

Prefer an inline source map for the first vertical slice to avoid unrelated map-fetching and file-URL issues. Follow with external source-map coverage using stable URLs.

The production build may continue disabling source maps unless explicitly configured otherwise.

Verify that DevTools displays src/main.jsx and that a breakpoint in JSX binds to the correct generated location in dist/main.js.

13. Add opt-in launch configuration

Provide a documented configuration API and command-line integration for hosts, for example:

--webscene-inspect=127.0.0.1:9229
--webscene-inspect-brk=127.0.0.1:9229

Equivalent managed options should support applications that do not use command-line parsing.

Required behavior:

  • inspector disabled by default;
  • explicit address/port configuration;
  • port 0 support for automatic ephemeral-port selection where practical;
  • actual endpoint printed to the development log;
  • inspect-brk waits before application scripts execute, but keeps the host responsive enough for discovery and connection;
  • clear diagnostics for address conflicts, unavailable Inspector builds, shared-isolate restrictions, and unsupported platforms.

14. Security requirements

A CDP connection permits arbitrary JavaScript execution and inspection of application state. Treat the endpoint as privileged.

  • Bind to loopback by default.
  • Require an explicit opt-in before listening.
  • Include an unguessable target/session token in the WebSocket URL or require an equivalent authorization mechanism.
  • Do not expose the endpoint on all interfaces without a separate explicit unsafe-development option.
  • Reject unexpected Origin values or document the chosen local-development origin policy.
  • Bound message size, queue depth, and session count.
  • Do not log complete Inspector messages by default because evaluated expressions and object values may be sensitive.
  • Ensure published Release applications do not silently open a debug port.
  • Document that enabling the endpoint grants debugger-level control of the application.

Expected initial DevTools functionality

The first complete implementation should enable:

  • target discovery through chrome://inspect;
  • DevTools Sources panel;
  • DevTools Console panel;
  • Runtime.evaluate;
  • script discovery and source retrieval;
  • URL and location breakpoints;
  • pause and resume;
  • step into, over, and out;
  • pause on exceptions;
  • call frames and scope inspection;
  • evaluation on a paused call frame;
  • CPU profiling;
  • V8 heap inspection/profiling, subject to the Inspector build configuration;
  • original JSX/TypeScript debugging when valid source maps are supplied.

V8 Inspector alone does not supply WebScene's browser/renderer domains. The following are follow-up work rather than blockers for JavaScript source debugging:

  • a native WebScene DOM tree in the DevTools Elements panel;
  • computed CSS and rule editing;
  • WebScene layout highlighting and hit testing;
  • network/resource timing and request inspection;
  • storage/application panels;
  • DOM mutation and event-listener breakpoints backed by WebScene DOM operations;
  • React DevTools component, props, hooks, and state inspection.

Chrome DevTools may show unsupported tabs or issue unsupported browser-domain commands. Those commands should fail cleanly without breaking the V8 debugging session.

Suggested implementation phases

Phase 1: Native protocol proof

  • Build/link V8 Inspector.
  • Register the root context.
  • Create one native Inspector session.
  • Dispatch Runtime.enable, Debugger.enable, and Runtime.evaluate in a native test.
  • Capture responses and Debugger.scriptParsed notifications through an in-memory channel.

Phase 2: Breakpoint and pause-loop proof

  • Add worker command queues.
  • Implement the paused nested message loop.
  • Set a breakpoint by URL.
  • Execute a script, receive Debugger.paused, evaluate on a call frame, step, and resume.
  • Verify engine disposal and debugger disconnect while paused.

Phase 3: Native ABI and managed bridge

  • Export connect, dispatch, take-message, and disconnect operations.
  • Add ABI and P/Invoke tests.
  • Add a managed asynchronous Inspector session wrapper.

Phase 4: Chrome transport

  • Add or reuse lightweight CDP discovery/WebSocket transport.
  • Publish a WebScene target through /json/list.
  • Forward raw Inspector JSON bidirectionally.
  • Connect Chrome DevTools through chrome://inspect.

Phase 5: Source maps and 7GUIs validation

  • Enable development source maps.
  • Debug src/main.jsx rather than only dist/main.js.
  • Pause in the Counter click handler after interacting with the native Uno window.
  • Verify locals, stepping, watches, console output, and resume.

Phase 6: hardening and documentation

  • Add security defaults and authorization/token handling.
  • Add queue/backpressure limits.
  • Verify navigation, iframes, multiple sessions, shutdown, and unsupported commands.
  • Document Chrome DevTools and IDE connection workflows.
  • Measure inspector-disabled startup, memory, and runtime overhead.

Testing requirements

Native unit/integration tests

  • Inspector creation and destruction with the V8 isolate.
  • Root context creation/destruction notifications.
  • Iframe context registration and teardown.
  • Runtime.enable and Debugger.enable responses.
  • Debugger.scriptParsed includes the expected script URL.
  • Runtime.evaluate returns primitive and object results.
  • Debugger.setBreakpointByUrl resolves a breakpoint.
  • execution produces Debugger.paused with real V8 call frames.
  • paused evaluation and Debugger.resume work.
  • stepping works without processing unrelated page tasks while paused.
  • pause-on-caught and pause-on-uncaught-exception behavior.
  • unhandled promise rejection reporting.
  • console message forwarding.
  • disconnect and engine disposal while running and while paused.
  • bounded inbound/outbound queue behavior.
  • explicit behavior under shared-isolate mode.

ABI and managed tests

  • ABI symbol/version validation on every native runtime RID.
  • UTF-8 messages larger than the caller's first buffer are copied using the established required-size pattern.
  • session IDs cannot be reused after disconnect.
  • managed cancellation and disposal do not leak sessions or block the worker.
  • availability callbacks remain non-blocking and never re-enter the native engine.

CDP transport tests

  • /json/version returns actual protocol/runtime metadata.
  • /json/list returns a valid WebScene target and WebSocket URL.
  • WebSocket messages are forwarded unchanged in both directions.
  • asynchronous V8 notifications are delivered without a pending request.
  • multiple sessions are either supported correctly or rejected with a documented error.
  • invalid target IDs, oversized frames, malformed JSON, and unauthorized connections fail safely.

End-to-end acceptance test

Use the React 7GUIs WebScene host as the validation application:

  1. Build a development bundle with source maps and embedded source content.
  2. Start the Uno WebScene application in inspector mode.
  3. Discover the target through /json/list.
  4. Connect a CDP client and enable Runtime and Debugger.
  5. Observe Debugger.scriptParsed for the bundle and its source map.
  6. Set a breakpoint in the original src/main.jsx Counter event handler.
  7. Trigger the Counter button through native input.
  8. Receive Debugger.paused at the original source location.
  9. Assert that call frames and local React handler state are inspectable.
  10. Evaluate an expression on the paused call frame.
  11. Step once and resume.
  12. Verify the application remains responsive and the Counter update completes.
  13. Disconnect DevTools and shut down without native or managed leaks.

Acceptance criteria

  • Inspector support is opt-in and no port is opened by default.
  • A WebScene target is discoverable from chrome://inspect.
  • Chrome DevTools connects without a protocol translation layer for V8-owned domains.
  • Runtime.enable and Debugger.enable are served by the actual WebScene V8 isolate.
  • Loaded WebScene scripts appear in the Sources panel with stable URLs.
  • Breakpoints can be set in generated JavaScript.
  • With a valid source map, a breakpoint can be set and hit in original JSX.
  • Pause, resume, step into, step over, and step out work.
  • Paused call frames, scopes, locals, watches, and evaluation work.
  • Console log/warn/error messages appear in DevTools without duplication.
  • Synchronous exceptions and unhandled promise rejections are visible with useful stacks.
  • The native UI remains responsive while JavaScript is paused.
  • Navigation, debugger disconnect, and application shutdown cleanly release Inspector state.
  • Shared-isolate behavior is explicitly supported or explicitly rejected in inspector mode.
  • Inspector-disabled builds/runs show no material startup or steady-state regression.
  • The endpoint is loopback-only and protected by default.
  • Chrome DevTools and IDE attach instructions are documented.
  • Unsupported DOM/Page/Network commands fail cleanly and do not terminate the V8 session.

References

Activity

  1. wieslawsoltes commented on Aug 3, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Full source editor/debugger client and validation addendum

    This addendum makes the latest requirement a governing constraint for every implementation detail in this issue:

    We want to implement full source code editor and debugging features in code editor in inspector it already has some foundation fro Avalonia edit extension we did but we need full vs code debug experience, do it along working on current goals

    The WebScene runtime work is therefore not complete when Chrome can merely attach. Every protocol, lifecycle, source-identity, source-map, pause-loop, and transport decision must also provide enough faithful V8 information for the CDP Inspector application's source editor to deliver a VS Code-class debug workflow. The current client-side implementation is tracked by CDP PR #109.

    1. WebScene-to-editor debugging contract

    For the full source editor/debugger requirement, WebScene must expose the real V8 Runtime, Debugger, Profiler, and HeapProfiler protocol without translating or synthesizing debugger state. The Inspector editor must receive stable script IDs and URLs, exact zero-based line/column positions, source-map URLs, execution-context lifecycle events, breakpoint resolution events, pause reasons/data, call-frame IDs, scope chains, remote-object IDs, async stack traces, exception details, and console stack traces.

    The contract must support at least:

    • enumerating runtime scripts and opening generated sources;
    • retrieving source with Debugger.getScriptSource;
    • searching loaded source with Debugger.searchInContent;
    • URL-, regex-, script-, and exact-location breakpoints;
    • breakpoint resolve/remove/enable/disable and persistence across navigation/reload;
    • pause, continue, step over, step into, step out, and restart frame;
    • pause on none/uncaught/all exceptions;
    • call stack, async call stack, scopes, locals, watches, and expression evaluation;
    • Runtime.getProperties, object groups, object release, previews, getters, and exception-safe formatting;
    • Debugger.evaluateOnCallFrame with side-effect/error reporting;
    • live edit through Debugger.setScriptSource, including compile errors, changed call frames, restart requirements, and source refresh;
    • blackboxing/skip-list behavior needed by a VS Code-style editor;
    • CPU and heap profiling while using the same target/session transport.

    Every unsupported V8 command must return the original Inspector error response and must not destabilize the session.

    2. Original React/TypeScript source experience

    For the full source editor/debugger requirement, generated bundle debugging alone is insufficient. Development builds must emit valid source maps with sourcesContent; WebScene must preserve canonical ScriptOrigin, sourceURL, and sourceMappingURL data; and the transport must leave Debugger.scriptParsed fields unchanged.

    Acceptance must cover:

    • opening original .jsx, .tsx, .js, and .ts sources in the Inspector editor;
    • setting a breakpoint in original React event-handler code before the bundle executes;
    • binding that breakpoint to the correct generated location;
    • showing the original source and mapped paused line when the breakpoint hits;
    • mapping call-frame locations and stack navigation back to original sources;
    • preserving multiple source roots, relative paths, URL-encoded paths, inline maps, external maps, and embedded source content;
    • displaying a clear generated-source fallback when a source map is missing or invalid;
    • documenting that V8 exposes JavaScript execution state, while React component/hook inspection requires a separate React DevTools bridge.

    3. Inspector editor interaction requirements

    For the full source editor/debugger requirement, the CDP Inspector app must consume the WebScene target exactly as it consumes Node or Chrome V8 targets. Its source workspace must provide a real code-editor experience rather than a read-only protocol viewer:

    • editable documents, syntax highlighting, line numbers, minimap, selection, find, source search, dirty state, save/apply-live-edit, and compile-error feedback;
    • breakpoint gutter, enabled/disabled/unbound/resolved states, conditional and logpoint metadata when supported, and an active-statement marker;
    • debugger toolbar and keyboard commands for continue/pause, stepping, restart frame, breakpoint toggle, and live-edit save;
    • call-stack navigation, scope/property expansion, watch add/remove/refresh, hover/selection evaluation, and a debug console;
    • exception breakpoint controls, blackboxing controls, source-map status, connection/target status, and graceful capability gating;
    • correct behavior during navigation, target replacement, reconnect, debugger disconnect, engine shutdown, and editor-layout restoration.

    WebScene implementation choices must be validated against these consumers and may not rely on Chrome DevTools-only behavior that prevents another conforming CDP client from debugging the same isolate.

    4. Required development validation matrix

    For the full source editor/debugger requirement, development must continuously exercise both protocol correctness and visible editor behavior:

    1. Native/in-memory V8 Inspector session — enable Runtime/Debugger, enumerate scripts, evaluate, set and hit a breakpoint, inspect scopes, step, resume, live-edit, profile, disconnect, and dispose while paused.
    2. Headless remote Node session — connect the CDP Inspector app to a real node --inspect target and run deterministic integration flows for source loading, breakpoints, watches, call stacks, restart frame, evaluation, source search, and live edit.
    3. Headless WebScene session — run the real WebScene V8 target with source maps, trigger native input, pause in original React source, evaluate/step/resume, and verify the UI completes its work.
    4. Real Chrome browser CDP session — launch Chrome with a dedicated remote-debugging profile and verify target discovery, Runtime/Debugger capabilities, scripts, evaluation, pause/step/resume, and clean detach.
    5. Real CDP Inspector desktop app through Computer control — operate the packaged Release app as a user would, connect to Node, Chrome, and WebScene targets, interact with the source editor/debugger UI, and capture screenshots of connected, paused, mapped-source, watch/scope, and live-edit states.
    6. Remote CDP controlling the Inspector itself — expose the Inspector Avalonia app's own CDP endpoint while it is debugging a V8 application, then use an independent CDP client to inspect/control the Inspector UI. This validates the two simultaneous sessions and detects reentrancy, dispatcher, socket-ownership, and target-selection defects.
    7. Release/NativeAOT validation — run the sample and packaged Inspector in Release mode, including DOM discovery, box model, input dispatch, recording/replay, and all V8 debugger flows; Debug-only success is not sufficient.

    Each end-to-end run must save a machine-readable report and screenshots. Failures must retain enough protocol trace and target metadata to distinguish runtime, transport, mapping, and client/editor defects without logging sensitive expression values by default.

    5. Additional headless integration tests

    For the full source editor/debugger requirement, add repeatable tests covering:

    • target discovery against Node, Chrome, and WebScene /json/list variants;
    • enable ordering before Runtime.runIfWaitingForDebugger;
    • notifications arriving before, between, and after command responses;
    • multiple outstanding requests, monotonically increasing IDs, reconnect, cancellation, isolated event subscribers, and exact socket/reader ownership;
    • script parsing before/after the editor panel is opened;
    • breakpoints set before a matching script loads;
    • pause at original-source and generated-source locations;
    • nested objects, getters throwing exceptions, unavailable/optimized-out values, cyclic graphs, and object release;
    • watch evaluation across steps and frame changes;
    • live-edit success, compile error, stack changed, and edit while running/paused;
    • navigation and context destruction without stale sources, remote objects, or breakpoint bindings;
    • debugger disconnect and application shutdown while running and while paused;
    • source-map edge cases and missing-source fallback;
    • simultaneous remote control of the Inspector app while its V8 debug session is paused;
    • Release/NativeAOT JSON payload serialization for DOM attributes, box-model quads, selectors, and debugger metadata.

    6. Screenshot evidence required for acceptance

    For the full source editor/debugger requirement, attach or link screenshots showing:

    • WebScene target discovery;
    • original React/TypeScript source open in the Inspector editor;
    • bound breakpoint in original source;
    • paused active line with breakpoint gutter and debugger toolbar;
    • populated call stack, scopes/locals, and watches;
    • debug-console evaluation on the selected frame;
    • live-edit applied and compile-error presentation;
    • real Chrome target session;
    • real Node target session;
    • the Inspector app being remotely inspected/controlled while it is debugging another V8 target.

    Screenshots are validation artifacts, not substitutes for automated assertions; both are required.

    7. Expanded definition of done

    For the full source editor/debugger requirement, all existing acceptance criteria remain in force and the issue is additionally complete only when:

    • The WebScene V8 target works unchanged with Chrome DevTools and the CDP Inspector editor.
    • The Inspector editor provides the source, breakpoint, stepping, call-stack, scope, watch, evaluation, exception, live-edit, source-map, and profiling workflows listed above.
    • A breakpoint set in original React/TypeScript source binds and pauses at the correct mapped location.
    • Headless Node, Chrome, and WebScene sessions run deterministically in CI where platform support permits.
    • A packaged Release Inspector app is exercised through desktop Computer control.
    • The Inspector app can itself be inspected over remote CDP while its separate V8 debugging session remains usable.
    • Release/NativeAOT tests cover protocol payload construction and UI record/replay flows.
    • Machine-readable reports and screenshot evidence are retained for the acceptance run.
    • Unsupported browser domains fail cleanly without degrading the source-debugging session.
    • Security, pause-loop responsiveness, disconnect, navigation, multi-session policy, backpressure, and shutdown requirements are verified.

    This addendum intentionally keeps WebScene's isolate/Inspector responsibilities separate from the CDP Inspector app's editor responsibilities, while treating the complete VS Code-style workflow as the cross-repository acceptance target.

  2. wieslawsoltes commented on Aug 3, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Implementation status update from CDP PR #109: the Inspector now has persistent rich breakpoints (standard, conditional, and logpoints), breakpoint activation and reconnect rebinding, async stack display, ignore-list/blackboxing controls, editable paused-frame variables, hover and selection evaluation, live edit, watches, and hardened standalone V8 transport behavior. We validated the full remote chain by controlling the packaged Inspector through its own CDP endpoint while it debugged a real paused Node V8 process (33/33 steps), plus real Chrome/Node protocol tests, headless UI tests, Playwright, and Computer Use screenshots. WebScene still needs to expose the standard V8 Inspector discovery/WebSocket endpoint and preserve script URLs/source-map metadata as detailed above; once it does, the same UI and protocol paths apply without a WebScene-specific debugger dialect.

  3. wieslawsoltes commented on Aug 3, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Status update after the latest WebScene and CDP pushes:

    • WebScene PR Add end-to-end WebScene V8 Inspector debugging #8 now exposes a real attachable V8 Inspector target through Avalonia and Uno, including inspect-brk startup and custom local documents.
    • CDP PR Invalid: packaged pointer coordinates were mapped from Retina pixels incorrectly #109 now contains a repeatable environment-gated WebScene React acceptance test. It verifies the pre-execution wait barrier, external source map and sourcesContent, original main.jsx breakpoint mapping, pause in increment, paused-frame evaluation, React closure scopes (count = 0 and setCount), step-over, resume, and rendered result 1.
    • The acceptance run emits a machine-readable JSON report containing target/source identities, original and generated lines, function name, pause count, closure value, and final rendered result.
    • The real run exposed a WebScene host-boundary defect: Runtime.evaluate could schedule a Promise microtask that was never drained under V8's explicit microtask policy. WebScene now performs a microtask checkpoint after each outer Inspector task while keeping nested paused-loop commands isolated from page microtasks.
    • Native regressions now cover direct-script and Runtime.evaluate pause/step/resume flows plus Promise microtask draining.
    • Release validation passed: all four native CTest targets, Avalonia tests 38/38, Uno desktop build with zero warnings/errors, CDP Inspector tests 38 passed plus the separately enabled real WebScene acceptance.
    • The packaged Inspector visibly opened original main.jsx, hit the mapped breakpoint, and displayed count/setCount. Its own remote CDP endpoint successfully resumed the separate paused WebScene V8 session.

    Current screenshots and machine-readable reports are retained in the local acceptance artifacts; both draft PR descriptions link the cross-repository implementation and validation. CI is running for WebScene b1e4598 and CDP e09587c.

  4. wieslawsoltes commented on Aug 3, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Implementation status update from draft PR #8:

    • Remote Inspector discovery is authenticated for non-loopback bindings and no longer discloses its bearer credential before authorization (decb56b).
    • Managed Inspector connect/send/drain/disconnect calls now share an engine-lifetime lease with destruction, including concurrent send/destroy stress coverage (094b25f).
    • Inspector-only console, exception, promise-rejection, and async-stack instrumentation is inactive when no session exists (9a11ce7).
    • Pull requests that touch the native/Inspector surface now compile and test a V8-enabled osx-arm64 runtime with the pinned patched SDK (bbd0d39).
    • Remote command-line launch requires a caller-known 32+ character WEBSCENE_INSPECT_TOKEN, never a generated secret discoverable only inside the app (2d68f2d).

    All four PR review threads are resolved. Standard CI is green on Ubuntu/macOS/Windows; local Release validation is native CTest 4/4, Avalonia net10 43/43, tooling 18/18, and Uno clean. The dedicated V8 PR lane is currently executing its full native test/package/WPT/interop step: https://github.com/wieslawsoltes/WebScene/actions/runs/30843011441

    Cross-repository authored TypeScript/JavaScript live edit remains validated through CDP PR #109: original source-map mutation is dry-run and applied with Debugger.setScriptSource, and the real React WebScene target executes the replacement source.

  5. wieslawsoltes commented on Aug 3, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Performance acceptance architecture update (9a1d518): Inspector is now a separate compile-time runtime flavor. Production builds default to WEBSCENE_NATIVE_ENGINE_ENABLE_V8_INSPECTOR=OFF, which removes the Inspector dependency, state, queues, hooks, and worker polling; diagnostic builds opt in with --v8-inspector / -V8Inspector and advertise WEBSCENE_ENGINE_BUILD_FEATURE_V8_INSPECTOR plus v8Inspector:true package metadata.

    Matched Release package validation on the same pinned V8 SDK passed native CTest 4/4, required WPT 1/1, a 12,800-operation interop race with zero faults/leaks, NuGet creation, and consumer build for both flavors. Production is 31,108,688 bytes with no Inspector implementation markers; diagnostics is 31,888,736 bytes, isolating the 780,048-byte feature cost from ordinary applications.

  6. wieslawsoltes commented on Aug 3, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Remaining literal Chrome DevTools parity after the V8 source-debugging stage

    PRs CDP #109 and WebScene #8 define the current stage boundary: authoritative V8 Inspector transport and lifecycle, Chrome discovery/attachment, Runtime/Debugger/Profiler/HeapProfiler, source maps, authored JS/TS/JSX mutation, breakpoints, pause/stepping/scopes/watches, live edit, WebAssembly debugging, and the compact Inspector source/debug workspace.

    The following work remains for literal Chrome DevTools browser parity. It should continue under this issue after the current stage merges; it is not silently treated as complete by the V8 source-debugging PRs.

    1. WebScene browser and renderer domains

    • Implement a WebScene-owned Target / Page lifecycle model, frame tree, navigation events, document metadata, reload, screenshot, and screencast semantics where WebScene can support them.
    • Implement a stable native DOM node identity model and CDP projection: document/tree retrieval, child requests, attribute/text mutations, search, node resolution, mutation events, backend node IDs, iframe ownership, and navigation invalidation.
    • Implement CSS matched rules, inline styles, computed styles, stylesheet/source ranges, rule/property mutation, pseudo-state forcing, and source mapping back to authored CSS.
    • Implement Overlay inspect mode, hover/selection highlighting, box-model geometry, hit testing, rulers, and layout overlays for flex/grid where supported.
    • Implement Network request/response lifecycle events, headers, timing, cache/service state, bodies, failures, initiators, redirects, and WebSocket/resource visibility from the native loader.
    • Implement Storage / Application coverage for local/session storage, cookies or explicitly unsupported cookie behavior, cache data, quotas, and origin clearing.
    • Implement browser-backed DOMDebugger, event-listener, DOM mutation, XHR/fetch, instrumentation, and resource breakpoints.
    • Publish an explicit supported-command matrix; unsupported browser commands must return deterministic protocol errors without damaging the V8 session.

    2. Full VS Code-class source editor in the CDP Inspector

    • Integrate a real JavaScript/TypeScript language service, including diagnostics, completion, signature help, hover, go-to definition, references, rename, symbols, semantic tokens, formatting, and import/project awareness.
    • Add reversible pretty-printing for minified JavaScript with breakpoint, execution-line, search-result, and live-edit location mapping.
    • Add a persistent Debug Console with command history, multiline editing, completion, object-tree expansion, copy/export, evaluation context selection, and console/runtime event interleaving.
    • Complete editor navigation UX: reusable tabs, preview/pinned tabs, breadcrumbs, history, quick open, command palette, global symbol search, split editors, and keyboard-remappable commands.
    • Complete breakpoint UX: inline condition/log/hit-count editing, grouping, enable/remove-all actions, exception filters, unresolved diagnostics, source-map rebinding status, and multi-session ownership.
    • Add multi-target/session/thread debugging, including target selection, per-session pause state, simultaneous Node/Chrome/WebScene targets, and safe reconnect/state restoration.
    • Complete workspace mutation semantics for JS/TS/framework files: filesystem watchers, disk/runtime conflict UI, undo/redo across regeneration, atomic writes, source-map refresh, and rollback.
    • Finish accessibility, focus order, automation metadata, screen-reader naming, high-contrast rendering, keyboard-only operation, and compact/responsive layouts at supported window sizes.

    3. Framework-aware debugging

    • Add React DevTools bridge support for component trees, props, hooks/state, owner stacks, profiling, highlight/update overlays, and version negotiation.
    • Define equivalent extension contracts for Vue/Svelte and framework-specific authored-source regeneration without moving V8 protocol ownership out of V8.

    4. Parity verification and release gates

    • Maintain a machine-readable domain/command/event parity matrix against the pinned V8 and Chrome protocol versions.
    • Run real Release sessions against WebScene, Node, and Chrome in headless and visible modes; validate Chrome DevTools and the packaged CDP Inspector concurrently.
    • Add end-to-end fixtures for navigation, iframe replacement, worker/realm handling where supported, async stacks, exceptions/rejections, profiling, heap snapshots, live edit, source-map mutation, and reconnect while paused.
    • Capture deterministic screenshots and accessibility trees for compact, standard, and narrow source/debug layouts.
    • Keep production WebScene performance matched to main, with the Inspector compiled out by default and repeatable startup/CPU/memory measurements.
    • Require clean cross-platform CI, package/consumer smoke, security tests, protocol fuzz/backpressure tests, and no unresolved review threads before each preview release.

    Current-stage closeout

  7. wieslawsoltes commented on Aug 3, 2026

    @wieslawsoltes
    CollaboratorAuthor

    New exact-binary application proof is available in PR #8: the real 7guis-React WebSceneHost runs against the Inspector-enabled V8 binary, opens original source-mapped main.jsx, resolves and pauses a React breakpoint, exposes call stack/scopes/watch state, supports F10/F5 through the packaged CDP Inspector. See the validation record with screenshots. Remaining Chrome DevTools parity work stays tracked by the detailed backlog above.

  8. wieslawsoltes commented on Aug 4, 2026

    @wieslawsoltes
    CollaboratorAuthor

    CDP source-editor and V8 validation stage update

    The next CDP editor/debugging slice is now on CDP main in four granular commits:

    • wieslawsoltes/CDP@7c41149 — embedded TypeScript 5.9 language service running in-process through Jint, with completion, hover, diagnostics, signature help, definition, references, rename, symbols, semantic classifications, and formatting APIs for JS/JSX/TS/TSX.
    • wieslawsoltes/CDP@883b063 — Sources editor wiring for cancellable completion and hover plus debounced diagnostics; paused V8 runtime hover retains priority.
    • wieslawsoltes/CDP@1aff518 — NativeAOT-safe source-generated JSON construction for remote CDP requests and accessibility payloads.
    • wieslawsoltes/CDP@a581d20 — reproducible validation record with screenshot and recording.

    Validation at a581d20:

    • complete Inspector headless UI suite: 154/154
    • V8 Inspector suite: 39 passed, one environment-gated WebScene case skipped
    • language service: 3/3; accessibility: 10/10; protocol: 10/10
    • real Chrome: breakpoint, evaluation, resume, CPU profiler, heap profiler, and screenshot
    • real Node through CdpService: attach, breakpoint, pause, source/call-frame state, and 30-second heartbeat
    • packaged Release Inspector connected to real Node, paused in the actual fixture, loaded 71 scripts, and displayed source, call stack, locals, and watch state
    • the Inspector application was simultaneously controlled through its own remote CDP endpoint while debugging Node
    • complete Release solution build: zero errors

    Evidence:

    The language-service API surface is implemented, while issue #7 deliberately remains open for its remaining UI command wiring, import/project awareness, multi-target editor workflow, browser/renderer domains, and literal Chrome DevTools parity items. The next CDP preview release is pending the exact-head main CI result. WebScene PR #8 remains unmerged pending Dan final approval.

  9. wieslawsoltes commented on Aug 4, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Current-stage closeout

    CDP preview.33 is fully published: https://github.com/wieslawsoltes/CDP/releases/tag/v0.1.0-preview.33

    Release result:

    • exact release commit: wieslawsoltes/CDP@44a6b29
    • complete release workflow passed: https://github.com/wieslawsoltes/CDP/actions/runs/30878123419
    • 59 GitHub release assets, including Windows MSI/ZIP, Linux tar/DEB, macOS x64/arm64 tar/DMG, Inspector packages, and the new JavaScript language-service package
    • NuGet publication reported success for the complete package set, including Chrome.DevTools.Inspector 0.1.0-preview.33 and Chrome.DevTools.JavaScript.LanguageServer 0.1.0-preview.33
    • release notes link the validation record, WebScene PR, and this remaining-parity issue

    WebScene PR #8 current head is 16a8593:

    • corrected V8 exception line/column conversion (aeafd3d)
    • bounded aggregate inbound Inspector bytes (66fef97)
    • fixed the Windows net8 HttpListener shutdown race exposed by exact-head CI (16a8593)
    • Native V8 Inspector, Ubuntu, macOS, and Windows checks all passed
    • unresolved review threads: 0
    • merge state: CLEAN / MERGEABLE

    WebScene remains intentionally unmerged because Dan has not yet replaced the historical changes-requested review with final approval. The remaining literal Chrome DevTools parity backlog above stays open and authoritative.

  10. wieslawsoltes commented on Aug 4, 2026

    @wieslawsoltes
    CollaboratorAuthor

    CDP Sources JS/TS navigation and refactoring stage

    CDP main now wires the existing TypeScript semantic engine into the Inspector Sources UI as a project-aware editing workflow.

    Implemented:

    • bounded project synchronization from Sources workspace and cached V8 scripts: maximum 256 JS/TS documents and 8 MiB aggregate text; binary inputs are skipped
    • generated V8 script source caching after Debugger.getScriptSource
    • F12 go to definition and Shift+F12 references
    • F2 inline rename with identifier validation, multi-file workspace writes, preflight rejection of unsupported secondary runtime-script edits, and best-effort rollback if a remote write fails
    • Ctrl+Shift+O document symbols and a hierarchical Explorer Outline
    • Shift+Alt+F TypeScript formatting
    • signature help on opening parenthesis and comma without reloading the whole remote project
    • compact Outline, Refs, and Format actions in the existing source toolbar; the inline rename widget overlays the editor instead of adding another stacked panel
    • language actions are shown only for JS/TS-family files

    Granular commits:

    Release validation:

    • CDP.Inspector.Shared Release build: succeeded
    • JavaScript language service: 3/3 passed, including true cross-document definition/reference/rename semantics
    • focused Sources JS/TS headless tests: 2/2 passed
    • complete Inspector shared headless suite: 155/155 passed
    • generated screenshots: sources-typescript-completion.png and sources-typescript-navigation-rename.png

    This advances the code-editor parity lane but does not close issue #7. Remaining Chrome DevTools parity includes command palette/quick-open, search/replace UX, full semantic token presentation, richer peek/references UI, edits/history/diff UX, advanced breakpoint editor behavior, and broader browser/Node/WebScene acceptance matrices.

  11. wieslawsoltes commented on Aug 4, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Exact-head CI closeout

    CDP exact head dd3d9d2 is fully green after rerunning one unrelated Windows inactivity-abort flake:

    • Ubuntu, macOS, and Windows complete test matrices passed
    • WinUI 3, Uno, WPF, Avalonia, and Avalonia 11 NativeAOT integration passed
    • Linux, macOS, and Windows build/package jobs passed
    • final NuGet aggregation passed

    Workflow: https://github.com/wieslawsoltes/CDP/actions/runs/30880683936

    The first Windows attempt had no assertion failure: 670 RDP tests passed before the test host exceeded the existing 60-second inactivity guard during unrelated RdpFrameBufferTests teardown. The failed-job rerun passed without source changes. This JS/TS Sources stage is complete; issue #7 remains open for the documented remaining parity backlog.

  12. wieslawsoltes commented on Aug 4, 2026

    @wieslawsoltes
    CollaboratorAuthor

    CDP Sources navigation parity stage — exact-head closeout

    CDP main now includes the next compact VS Code-style source navigation slice in two granular commits:

    Implemented behavior:

    • Ctrl+P: fuzzy file/path search across workspace files and loaded V8 runtime scripts.
    • Ctrl+Shift+P: one command surface for editor navigation/refactoring plus debugger actions such as breakpoint, continue, pause, stepping, and run-to-cursor.
    • Ctrl+Shift+O: current JS/JSX/TS/TSX symbol search backed by the embedded TypeScript service.
    • Ctrl+T: bounded project-wide JS/JSX/TS/TSX symbol search across the loaded language-service project.
    • Up/Down selection, Enter execution, Escape close, double-click execution, editor focus restoration, result counts, fuzzy filtering, stable async request invalidation, and preservation of a query typed while symbols load.
    • The UI is a centered overlay inside the existing source editor split. It adds no stacked sidebar/debugger panels and retains the existing Explorer/Outline/editor/debugger split layout.

    Validation at exact CDP head 948ba6b:

    • focused TypeScript Sources suite: 3/3 passed, including actual Avalonia routed keyboard gestures, file filtering, command filtering, document symbol navigation, and project symbol discovery.
    • complete Inspector shared headless suite: 156/156 passed.
    • complete Release solution build: 0 errors.
    • exact-head .NET CI: all Ubuntu/macOS/Windows test matrices, all five NativeAOT lanes, all three platform build-and-pack jobs, and final NuGet aggregation passed: https://github.com/wieslawsoltes/CDP/actions/runs/30884388016
    • docs build passed: https://github.com/wieslawsoltes/CDP/actions/runs/30884387822
    • screenshot captured as artifacts/headless-screenshots/sources-command-palette.png and posted in the development thread for visual review.

    Review and cross-repository state:

    Issue #7 remains open. The next editor/debugger parity work still includes reusable preview/pinned tabs and history, search/replace and richer references/peek UX, semantic token presentation, advanced breakpoint editing/state, filesystem/runtime conflict and diff workflows, multi-target sessions, and the WebScene browser/renderer domain backlog.

  13. wieslawsoltes commented on Aug 4, 2026

    @wieslawsoltes
    CollaboratorAuthor

    V8 debugging milestone complete

    The cross-repository V8 debugging goal is complete at the agreed working-debugger boundary. Literal Chrome DevTools and VS Code parity remains follow-up work in this issue and is no longer a blocker for closing the implementation goal.

    Completed CDP stage

    • CDP PR Invalid: packaged pointer coordinates were mapped from Retina pixels incorrectly #109 is merged and CDP v0.1.0-preview.33 is published.
    • The Inspector supports discovery and attachment to Node, Chrome, and WebScene V8 targets; Runtime and Debugger sessions; pause, resume, stepping, breakpoints, call stacks, scopes, watches, evaluation, source maps, authored JS/TS/JSX mutation, live edit, profiling, heap tooling, WebAssembly debugging, and the compact Sources/debug workspace.
    • Post-release editor/navigation work is on CDP main at exact head 948ba6b, including the TypeScript language service, definition/references/rename/format/symbol workflows, Quick Open, Command Palette, and project/document symbols.
    • Exact-head CI is green across Ubuntu, macOS, Windows, all NativeAOT lanes, platform packaging, NuGet aggregation, and docs: https://github.com/wieslawsoltes/CDP/actions/runs/30884388016

    Completed WebScene implementation stage

    • WebScene PR Add end-to-end WebScene V8 Inspector debugging #8 is implementation-complete at exact head 16a8593.
    • Native V8 Inspector lifecycle, context/session ownership, paused-loop control, secure discovery/WebSocket hosting, backpressure limits, source maps, live edit, exception handling, multi-session behavior, compile-time production/diagnostic flavors, and shutdown/race hardening are implemented and covered.
    • Native V8 Inspector, Ubuntu, macOS, and Windows checks all pass.
    • The PR is CLEAN / MERGEABLE and has zero unresolved review threads.
    • Dan is already requested for review. The PR remains intentionally unmerged until Dan replaces the historical changes-requested review with final approval.

    End-to-end acceptance evidence

    Deferred work

    This issue remains open as the authoritative backlog for the already documented remaining browser/renderer domains, full editor and advanced breakpoint UX, multi-target debugging, framework tooling, mutation conflict/history workflows, accessibility/layout polish, parity matrices, and expanded release gates. Those items are future parity stages, not defects preventing current V8 debugging from working.

  14. wieslawsoltes commented on Sep 18, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Disposition after live verification:

    Removing vscode-oss/planned, detaching this completed implementation milestone from #227, and closing it as completed. #397 is intentionally outside the current release graph.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions