v0.1.1167 Aug 2026·JavaScript & JIT, DevTools, Tabs & interface

DevTools debugger: source-line breakpoints

The biggest debugger piece lands: real, click-a-line breakpoints. Set a breakpoint on a source line and execution pauses THERE, with the live scope - every local and block variable at its actual value at that point in the code - not just where a `debugger;` statement happens to sit. It works by threading a source-line number through the lexer, parser and compiler into a compile-time line->bytecode table, with NO extra instruction in the running code, so a page that is not being debugged runs exactly as before (the whole conformance suite is unchanged and the just-in-time compiler is untouched). When a breakpoint is armed the engine runs the interpreter so the breakpoint can fire even inside a hot loop, and a fast flag means a normal run pays essentially nothing. This is the capability that makes the debugger usable for real work - set a breakpoint, reload, inspect. The Debugger panel gets a break-on-line input. DevTools moves 26 to 28; overall holds at 51.

Parity with the reference browser

74overall, as of v0.1.343

Web APIs / DOM surface42

Security architecture66

GPU / graphics acceleration68

DevTools / extensions72

Networking85

Media85

Accessibility85

Real-world site compatibility99

HTML parsing100

CSS parsing + selectors100

Layout: block / flex / grid / tables / writing-modes100

Paint + visual100

JavaScript language100

JavaScript performance (JIT)100

HTML parsing100

What changed 3 changes

DevTools	Source-line breakpoints (Debugger.setBreakpointByUrl): a 1-based source line is threaded lexer -> parser -> compiler into a compile-time line->bytecode table (a Stmt::Line marker that emits NO runtime op), so the running bytecode and the JIT are byte-for-byte unchanged. Set a breakpoint and execution pauses at that line with the live scope; verified a breakpoint on `var y = x + 1;` pauses with x=41 in scope, an unrun line never fires, and clearing disarms.
JavaScript & JIT	Zero-cost when off, correct inside loops: the interpreter reads a fast "any breakpoint armed" flag once per entry and only then checks the current position, so a non-debugging run pays a predicted-not-taken branch and the conformance gate is unchanged (6375/6375). While a breakpoint is armed the loop just-in-time compiler steps aside so the breakpoint fires even in a hot loop - and it steps right back in when breakpoints are cleared (JIT tests all green).
Tabs & interface	Wired through: the CDP Debugger.setBreakpointByUrl / setBreakpoint / removeBreakpoint methods, __debug_set/clear_breakpoint natives, and a break-on-line input with line chips in the visual Debugger panel. This is the biggest single step toward a full-featured debugger; stepping and a Sources gutter are the follow-ons. Built on the v0.1.112-115 debugger (breakpoints, pause-on-exceptions, evaluate-on-frame).