Workflow Dependencies graph can become unreadable / inaccessible when content overflows the container

[timothymiller]

Description

The Workflow Dependencies graph rendered by web_src/js/components/WorkflowGraph.vue (introduced in #36248) lays out jobs horizontally by dependency level. For workflows with many parallel paths or several dependency levels, the SVG can be much wider than its container (e.g. a ~2940px-wide SVG inside a ~690px container).

The container uses overflow: hidden, so the only ways to see clipped content are:

1. Click-and-drag to pan, or
2. Ctrl/Cmd + scroll to zoom out.

Both have UX problems:

• No discoverability. There's no visual cue (scrollbar, fade, "more →") that content is clipped. New users see a graph that just appears cut off on the right.
• Zooming out makes labels unreadable. minScale is 0.3, but job names become illegible well before that. For a workflow with ~20 jobs across 6 dependency levels, the only zoom level that fits the full graph leaves node labels too small to read.
• Saved state can leave the graph inaccessible. Per-workflow scale/translate is persisted in localUserSettings under actions-graph-states. If the user previously panned/zoomed to an awkward state, it's restored on next visit with no indication the visible viewport doesn't match the content. The "Reset view" button helps, but only if the user knows content is clipped.
• No scrollbar fallback. Touch/trackpad users without an obvious modifier-scroll affordance can't easily discover panning.

Steps to reproduce

1. Run a workflow with ~15+ jobs and 4+ dependency levels (any wide DAG).
2. Open the run page; observe the Workflow Dependencies section.
3. Several columns of jobs are clipped on the right with no scrollbar.

Expected behaviour

The graph should remain readable and all nodes should be reachable without requiring users to discover hidden pan/zoom gestures.

Suggested fix

Smallest possible change — make .graph-container natively scrollable, keeping pan/zoom as enhancements:

 .graph-container {
   flex: 1;
-  overflow: hidden;
+  overflow: auto;
   padding: 10px 14px 18px;
   ...
 }

A more thorough fix could additionally:

• Apply a sensible max-height so the graph doesn't push the rest of the page out of view on tall workflows.
• Skip restoring saved scale/translate if it would render content out of view (or always start from resetView() when the SVG fits the viewport at scale 1).
• Suppress the cursor: grab and pan handlers when the SVG fits the container, so the cursor matches actual behaviour.

Happy to open a PR with the minimal CSS change if maintainers prefer that approach, or with the more thorough fix if there's appetite for it. Wanted to check direction first since the current pan/zoom-only design appears intentional.

Screenshots

Gitea Version

1.26.0+ (introduced by #36248; reproducible against current main)

Can you reproduce the bug on the Gitea demo site?

Yes

Operating System

No response

Browser Version

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36

[RajGajjar-01]

Can this issue be assigned to me please ?