Skip to content

fix(graph): scope CSS to #graph and add fit-to-view for HTML viewer#4117

Open
A3Ackerman wants to merge 1 commit into
gastownhall:mainfrom
quickserve-ai:fix/graph-html-viewport-legend
Open

fix(graph): scope CSS to #graph and add fit-to-view for HTML viewer#4117
A3Ackerman wants to merge 1 commit into
gastownhall:mainfrom
quickserve-ai:fix/graph-html-viewport-legend

Conversation

@A3Ackerman

Copy link
Copy Markdown

Summary

bd graph --html is unusable on non-trivial graphs: the legend covers the viewport and graph nodes run off-screen even after Reset View. Two distinct bugs in the embedded HTML template:

  1. CSS scope blow-up. svg { width: 100vw; height: 100vh } matches every <svg> on the page — including the 30×10 legend swatches for "blocks" and "parent-child" edge types. Each swatch balloons to viewport size, stretching the #legend container to ~1500×1600 and covering the graph. Fix: scope to #graph.
  2. Initial-zoom does not actually fit. d3.zoomIdentity.translate(width/4, height/4).scale(0.8) is a fixed transform that doesn't read node positions; multi-layer graphs (x = 150 + layer*220) push deep-layer nodes off-screen to the right. Fix: real fitToView() that reads the post-simulation bounding box and transforms to fit with padding. Adds a "Fit View" button and repoints resetZoom() to it so the existing Reset View button behaves as users expect.

Template-only change. No public API surface, no behavior change for the DOT renderer.

Why

Continuation of recent graph-viewer fixes:

This addresses the remaining unusability of the rendered viewer itself. Followed CONTRIBUTING.md "one issue per PR" — did not bundle the adjacent observation that --all --html still emits N sub-graphs per connected component (that is a layout choice, not a CSS bug; happy to file separately).

Verification

  • Manually rendered against a real graph: legend ~134×190 (was ~1500×1600), graph auto-fits on initial render and on Reset View. Reproduced the bug + verified the fix on macOS Chrome.
  • make build — clean
  • golangci-lint run --build-tags gms_pure_go ./cmd/bd/...0 issues.
  • make test — hits an environmental hang in internal/utils/TestMain (testutil.EnsureDoltContainerForTestMain) on my local box, unrelated to a Go HTML template string change. I expect CI (with Docker) to run this cleanly; happy to investigate further if it doesn't.

Notes for reviewers

  • setTimeout(fitToView, 1500) rather than simulation.on("end", ...) — force simulations with strong charges don't naturally reach end without explicit alpha/alphaTarget discipline. The 1500ms heuristic works in practice; happy to revisit.
  • fitToView() caps scale at the existing zoom.scaleExtent([0.1, 4]) upper bound (Math.min(width/bboxW, height/bboxH, 4)).
  • Initial analysis and patch design by Syl (qcore crew); applied and verified upstream by me.

🤖 Generated with Claude Code

The HTML graph viewer was unusable for non-trivial graphs. Two distinct
bugs in cmd/bd/graph_export.go template:

1. CSS selector "svg { width: 100vw; height: 100vh }" matched every
   <svg> on the page, including the 30x10 legend swatches for "blocks"
   and "parent-child" edge types. Each swatch ballooned to viewport
   size and stretched the #legend container over the graph. Scope to
   #graph instead.

2. Initial zoom was a hardcoded "translate(width/4, height/4).scale(0.8)"
   that doesn't read node positions — multi-layer graphs ran off-screen
   to the right. Replace with a real fitToView() that reads the post-
   simulation bounding box and transforms to fit with padding. Also adds
   a "Fit View" button and repoints resetZoom() to call fitToView()
   (matches user expectation of the existing Reset View button).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@maphew

maphew commented Jun 16, 2026

Copy link
Copy Markdown
Collaborator

Thanks for the report. I’m doing a repro sweep and couldn’t find a concrete reproduction recipe in the current description or thread.

Could you add the smallest command sequence or setup that triggers this, including the bd version, storage mode, OS, and the expected vs. actual output? A scratch-repo repro is ideal if one is possible.

codex-gpt-5.5-medium on behalf of matt wilkie

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants