view screenshot hangs on headless Linux: chromium waits indefinitely for external resources

[wanguan2000]

Bug: view screenshot hangs on headless Linux (chromium waits indefinitely for external resources)

Environment

• OS: Rocky Linux 10.1
• OfficeCLI: v1.0.131 (linux-x64)
• Chromium: 149.0.7827.53 (headless=new)
• Network: external access OK (fonts.googleapis.com and cdn.jsdelivr.net reachable)

Steps to reproduce

officecli create test.docx
officecli add test.docx / --type paragraph --prop text="Hello" --prop size=48
officecli close test.docx
officecli view test.docx screenshot -o test.png   # hangs forever

Root cause

OfficeCLI's generated HTML references external CDN resources:

• fonts.googleapis.com/css2?family=...
• cdn.jsdelivr.net/npm/katex@0.16.11/dist/katex.min.css
• cdn.jsdelivr.net/npm/katex@0.16.11/dist/katex.min.js

Chromium in headless mode waits for these to fully load before taking the screenshot. Without --virtual-time-budget, it waits indefinitely even though the network is accessible.

Verified

• chromium-browser --headless about:blank → screenshot completes instantly ✅
• OfficeCLI's __resident-serve__ correctly discovers and spawns chromium with --headless=new --no-sandbox --disable-gpu --screenshot=... ✅
• Same chromium, same HTML file, but with --virtual-time-budget=10000 → screenshot completes in <2s ✅

Workaround

officecli view test.docx html -o test.html
chromium-browser --headless=new --no-sandbox --disable-gpu \
  --virtual-time-budget=10000 \
  --screenshot=test.png \
  file:///test.html

Suggested fix

Pass --virtual-time-budget (10000-15000ms) to chromium in screenshot mode, or inline critical CSS/fonts to avoid external dependency blocking.

Additional feedback

dump → batch and merge are excellent. Worth the install cost alone. 🚀

[goworm]

Confirmed and fixed — thanks for the clean diagnosis and the flag verification. We reproduced the hang against a stalled server (connection accepted, never answered) and found one thing worth noting beyond your report: --virtual-time-budget alone does not recover the truly-stalled case — virtual time never advances past a stalled render-blocking request. Your setup likely had slow-but-completing loads, which the budget does bound.

So the fix applies both caps to every chrome invocation (screenshot, dump-dom, sized capture):

• --virtual-time-budget=15000 — bounds slow loads, lets async JS (KaTeX/mermaid) finish
• --timeout=20000 — wall-clock backstop that forces capture even with a request still pending (the stalled case now exits in ~20s with the page rendered minus the dead resource)

Verified: the stalled-resource page hung indefinitely before and captures in ~22s after; normal documents are unaffected (~1–6s). Will be in the next release — until then your --virtual-time-budget workaround plus chromium's --timeout flag covers both cases.

Glad dump→batch and merge are earning their keep 🚀

[goworm]

Fixed in v1.0.132 — headless captures now carry both a virtual-time budget and a hard wall-clock timeout, so a stalled external resource can no longer hang the screenshot; it captures with whatever has loaded. Please upgrade and confirm on your Linux setup.