You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the Statistical Route view (Node Details → Traceroute → "Statistical (N routes)"), dense unions of many stored routes produce edges whose paths cross or run parallel through the same screen region. Nothing separates them unless they pass near a node glyph, so lines overlap and it becomes hard or impossible to hover the specific route you want.
Reported by @wilhel1812 with a screenshot showing a 24-route statistical union where multiple pink/purple curved edges overlap across a dense node grid.
Root cause
layoutTracerouteUnion (src/utils/tracerouteUnionLayout.ts:352-360) builds its obstacles array only from other nodes' glyph centers (graph.nodes), never from other edges, then routes each path around those glyphs via routeAroundGlyphs (reused from the [BUG] Traceroute strip: edges can visually overlap unrelated nodes/labels #4428 node-collision fix). Two edges whose independently-computed paths pass near each other are never pushed apart.
The module banner at src/utils/tracerouteUnionLayout.ts:58-61 documents this as intentional design decision D8 ("no lane translation — there is no competing leg to separate from"), which is correct for forward/return leg separation on a single route but leaves distinct routes' crossing paths unseparated in the statistical union.
Hover/hit-testing in src/components/traceroute/TracerouteStrip.tsx:706-731 draws one invisible widened polyline.edgeHit per edge, stacked in DOM/paint order with no z-index or cursor-proximity logic. Where two hit-targets overlap, only the one last in graph.edges array order receives the pointer/click event — not necessarily the line the user is visually trying to hover.
Requested fix
Some combination of:
Edge-to-edge collision avoidance (not just edge-to-glyph) in the union layout — at minimum nudge apart edges detected running near-parallel over a shared span.
On hover, prefer the edge whose path is geometrically nearest the cursor rather than whichever hit-target is last in DOM order.
Summary
In the Statistical Route view (Node Details → Traceroute → "Statistical (N routes)"), dense unions of many stored routes produce edges whose paths cross or run parallel through the same screen region. Nothing separates them unless they pass near a node glyph, so lines overlap and it becomes hard or impossible to hover the specific route you want.
Reported by @wilhel1812 with a screenshot showing a 24-route statistical union where multiple pink/purple curved edges overlap across a dense node grid.
Root cause
layoutTracerouteUnion(src/utils/tracerouteUnionLayout.ts:352-360) builds itsobstaclesarray only from other nodes' glyph centers (graph.nodes), never from other edges, then routes each path around those glyphs viarouteAroundGlyphs(reused from the [BUG] Traceroute strip: edges can visually overlap unrelated nodes/labels #4428 node-collision fix). Two edges whose independently-computed paths pass near each other are never pushed apart.src/utils/tracerouteUnionLayout.ts:58-61documents this as intentional design decision D8 ("no lane translation — there is no competing leg to separate from"), which is correct for forward/return leg separation on a single route but leaves distinct routes' crossing paths unseparated in the statistical union.src/components/traceroute/TracerouteStrip.tsx:706-731draws one invisible widenedpolyline.edgeHitper edge, stacked in DOM/paint order with no z-index or cursor-proximity logic. Where two hit-targets overlap, only the one last ingraph.edgesarray order receives the pointer/click event — not necessarily the line the user is visually trying to hover.Requested fix
Some combination of:
Related
Authored by NodeZero 0️⃣