Label geometry x=1433 corruption when dragging edge label - division by near-zero totalLength in getRelativePoint

[PeoTiko]

Preflight Checklist

• I agree to follow the [Code of Conduct](https://github.com/jgraph/drawio/blob/dev/CODE_OF_CONDUCT.md) that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Describe the bug
When dragging an edge label, it flies to an extremely distant position, causing the canvas to expand massively. The corrupted XML shows geometry x="1433" — far outside the valid range of -1 to 1 for relative mode.

To Reproduce

1. Create an edge with a label in draw.io
2. Drag the label along the edge
3. The label jumps to a far-off position
4. Open Extras → Edit Diagram — the XML shows an abnormally large x value in mxGeometry

Expected behavior
The label stays near the edge. geometry.x should remain within [-1, 1] in relative mode.

Root Cause (technical)
The bug is in mxGraphView.prototype.getRelativePoint in mxGraphView.js:

return new mxPoint(
    ((totalLength / 2 - length - projlen) / totalLength) * -2,
    yDistance / this.scale
);

When edgeState.length (totalLength) is zero or near-zero at the moment dragging begins, the division produces an extremely large value (e.g. 143.3), which then gets written into geometry.x as 1433 via moveLabel:

geometry.x = Math.round(pt.x * 10000) / 10000;

Corrupted XML example

<mxGeometry x="1433" y="-1" relative="1" as="geometry">

Suggested Fix
Clamp the result before returning:

if (totalLength === 0) {
    return new mxPoint(0, 0);
}
var resultX = ((totalLength / 2 - length - projlen) / totalLength) * -2;
resultX = Math.max(-1, Math.min(1, resultX));
return new mxPoint(resultX, yDistance / this.scale);

draw.io version: 28.1.1
Desktop:

• OS: Windows 11

Tested in incognito mode with extensions off: yes

Additional context
None.

[draw-io-triage-bot]

👋 Thank you for opening this issue!

---

Summary: The user reports that dragging an edge label can cause the label's geometry.x to be set to an extremely large value (e.g., 1433) due to a division by near-zero totalLength in mxGraphView.getRelativePoint, causing the label to fly off-screen and corrupting the diagram XML. They propose clamping the result to [-1, 1] and adding a zero-length guard.

---

📝 Additional Information Needed

To help us investigate this more effectively, could you please provide:

• Reproducible steps detail: The steps to reproduce are somewhat vague ('drag the label along the edge'). It would help to know the specific edge configuration that triggers near-zero totalLength — e.g., is this a self-loop, a zero-length edge where source and target overlap, or does it happen during a specific drag timing? A .drawio file demonstrating the issue before corruption would be very helpful.
• Browser: The user mentions Windows 11 and desktop but does not specify whether this is the Electron desktop app or a browser-based version, and if browser-based, which browser.
• Reproducibility rate: Is this consistently reproducible or intermittent? Understanding whether it's a race condition (edge state not yet computed) vs. a specific edge geometry would help prioritize.

We also have some questions:

• Can you provide a .drawio file (before corruption) that reliably reproduces this issue when you drag the label?
• What type of edge triggers this — a regular edge between two distinct nodes, a self-loop, or an edge where source and target nodes overlap or are very close together?
• Are you using the Electron desktop app or the browser version of draw.io?
• Does this happen every time you drag the label, or only intermittently (e.g., when dragging very quickly or immediately after creating the edge)?

📋 Bug Report Template

**Environment:**
- draw.io version: [e.g., web app / desktop 24.x.x / Confluence plugin]
- Browser (if web): [e.g., Chrome 120, Firefox 121]
- OS: [e.g., Windows 11, macOS 14, Ubuntu 22.04]

**Steps to Reproduce:**
1. Go to ...
2. Click on ...
3. See error

**Expected Behavior:**
What you expected to happen.

**Actual Behavior:**
What actually happened.

**Screenshots/Files:**
If applicable, add screenshots or attach the .drawio file.

---

---

_{🤖 This is an automated response to help with initial triage. A human maintainer will review this issue. If you've provided all the requested information, no further action is needed - we'll get back to you soon!}

[PeoTiko]

Thank you for the follow-up questions. Here are my answers:

1. Edge type: A regular Line edge (from the "General" shape library)
   between two distinct nodes. Not a self-loop, not a zero-length edge.

2. Client: Electron desktop app, Windows 11, draw.io version 28.1.1.

3. Reproducibility: Intermittent. It does not happen every time.
   No specific drag speed or timing was noticed when it occurred.

4. .drawio file: Unfortunately not available. The corrupted file was
   deleted after manually fixing the XML. The corrupted XML snippet
   provided earlier (geometry x="1433") is the only artifact remaining.

Additional findings that may help reproduce and understand the issue:

1. When the label flies away, the canvas does NOT expand immediately —
   the view stays in place. But after saving and reopening the file,
   the canvas expands to include the displaced label. This suggests
   draw.io recalculates the bounding box on load.

2. The corrupted label causes excessive whitespace when copying the
   diagram to a new page. The label itself is very small (just the
   number "1") and easy to miss, but it is still included in the
   selection bounds, so the whitespace appears.

3. The connection between the label and its parent edge appears broken
   in one direction: when selecting the entire diagram body (which
   includes the edge), the displaced label is NOT included in the
   selection. However, the label still references the edge as its
   parent in the XML.

4. Deleting the edge from the main diagram also deletes its label
   (since the label is a child of the edge). This removes the
   displaced label as well, and the canvas returns to normal.

These observations confirm that the root cause is the corrupted
geometry.x value persisted to XML, and the fix should prevent
out-of-range values from being written in the first place.