Debug visibilityDebug visibility for browser-side PDF runtimes
Browser Core Debug turns visual editing problems into inspectable runtime state, so a bad preview frame can be explained instead of guessed from a screenshot.
Technology previewPDFium WASM activeReplay enabled
Runtime pipeline
From PDF bytes to final composite, all inside the browser preview path.
Local-firstDeterministicReal-time previewBackend-authoritative export
Problem
What this changes
PDF editing bugs are often visual: old text remains visible, text appears twice, a white box appears, drag flickers, selection resolves to the wrong span or the preview feels slow. Screenshots show the symptom, but not why the browser drew it.
Browser Core approach
Runtime-first preview
Browser Core exposes product-level diagnostics for operations, render planning, dirty updates, textless cleanup, final composite safety, interaction ownership and frame timing. The goal is enough signal to diagnose behavior without exposing arbitrary low-level PDF internals.
What this solves
Shows whether the user is seeing backend-only state, backend plus local replay or blocked local preview
Separates rendering plan issues from tile cleanup, interaction ownership and performance timing
Helps identify unsafe fallback output before it becomes a trusted preview state
Makes visual bugs reproducible from runtime data instead of screenshots alone
Current status
Operation and replay visibility
Render graph and dirty update signals
Textless tile readiness
Final composite safety checks
Frame and composite timing