getDocumentBounds side effects

GoJS
1

I have a problem with the TextEditingTool that is scrolling to an invisible TextBlock (it jumps to a completely different place on the diagram). It looks like because it is invisible the first getDocumentBounds produces a Rect with {x: 0, y: 0}. But then the second call has correct x and y. I wouldn’t expect a getter to have side effects and modify its returned value just because it was called. Please confirm whether I’m not mistaken and getDocumentBounds has to be called twice to ensure correct result for invisible GraphObjects (getDocumentBounds isn’t idempotent).

In the example you can see that two consecutive getDocumentBounds calls produce different results:

Screenshot 2026-01-05 at 18.51.06
Screenshot 2026-01-05 at 18.51.061378×622 29.1 KB

<!DOCTYPE html>
<html lang="en">
  <body>
    <script src="https://gojs.net/latest/release/go.js"></script>
    <div id="sample" style="display: flex">
      <div
        id="diagramDiv"
        style="border: solid 1px black; width: 600px; height: 600px"
      ></div>
    </div>

    <script id="code">
      const diagram = new go.Diagram("diagramDiv");

      const $ = go.GraphObject.make;

      const nodeTemplate = new go.Node("Spot", {
        draggable: true,
        itemTemplate: $(
          go.Panel,
          go.Panel.Spot,
          $(go.Shape, "Circle", { desiredSize: new go.Size(10, 10) }),
          new go.Binding("alignment", "", (data) => data.spot)
        ),
      })
        .bindTwoWay("location", "location", go.Point.parse, go.Point.stringify)
        .add(
          new go.Shape("RoundedRectangle", {
            strokeWidth: 0,
            fill: "white",
            portId: "",
            fromLinkable: true,
            toLinkable: true,
            desiredSize: new go.Size(100, 100),
          }).bind("fill", "color"),
          new go.TextBlock({
            name: 'TextBlock',
            margin: 8,
            font: "bold 14px sans-serif",
            stroke: "#333",
            text: "Text",
            visible: false
          })
        )

      diagram.nodeTemplate = nodeTemplate;

      const nodes = [
        {
          key: "N1",
          text: "Alpha",
          color: "lightblue",
          location: "-12.51953125 117.89453125",
        },
      ];

      const links = [];
      diagram.model = new go.GraphLinksModel(nodes, links);
      setTimeout(() => {
        const node = diagram.findNodeForData(nodes[0]);
        // const textBlock = node.findObject('TextBlock'); // findObject returns null
        const textBlock = [...node.elements][1];
        console.log(textBlock.getDocumentBounds());
        console.log(textBlock.getDocumentBounds());
      })
    </script>
  </body>
</html>
2

Thank you again for the demo sample.

The reason that Panel.findObject isn’t working is because you have set the Panel.itemTemplate. Normally then setting the Panel.itemArray property either directly or via binding will cause all elements to be removed (except for the main element of some panel types such as “Spot”). So under normal usage, that TextBlock named “TextBlock” would immediately disappear from the Node. But you haven’t added a binding on the Panel.itemArray property, so that doesn’t happen. I think it’s an obscure bug that the internal mapping of names to elements is cleared too early, when Panel.itemTemplate is set.

I’m still looking into the apparent side-effects of calling GraphObject.getDocumentBounds.

3

Although it doesn’t explain the apparent non-idempotent behavior of that method call, you should realize that the bounds of a GraphObject that is not visible (or is contained by something that is not visible) really aren’t well defined.

So technically it is not a bug that you are getting different values, since the value is not defined.

4

Thank you for pointing this out. We have fixed this bug and it will be out with the next release, probably some time this week.

This happened because the invisible TextBlock has never been measured, and we mistakenly update some internal bookkeeping only partially when trying to get its bounds.

The thing to note is: The first value is sort-of more correct - it cannot place itself in document bounds, so its as correct as it can be. The second values are trash because the object has never really been measured. You can confirm this by setting the TextBlock to visible and then trying again, and you’ll see the Rect has different values:

rx: 23.60693359375, ry: 160.855615234375,

1 Like
5

Thank you for explanation of both findObject and getDocumentBounds issues. I’ll use the double call to getDocumentBounds until the next GoJS release.

6
7

I’ve checked the new release. The getDocumentBounds method produces the same result every time I call it. But I’m confused by the results. TextBlock.getDocumentBounds returns {x: 0, y: 0} even though node’s position is {x: 100, y: 100}. I’d expect TextBlock’s coordinates to be greater than 100. Could you explain?

Screenshot 2026-01-07 at 18.33.46
Screenshot 2026-01-07 at 18.33.461590×620 52.4 KB

<!DOCTYPE html>
<html lang="en">
  <body>
    <script src="https://gojs.net/latest/release/go.js"></script>
    <div id="sample" style="display: flex">
      <div
        id="diagramDiv"
        style="border: solid 1px black; width: 600px; height: 600px"
      ></div>
    </div>

    <script id="code">
      const diagram = new go.Diagram("diagramDiv");

      const $ = go.GraphObject.make;

      const nodeTemplate = new go.Node("Spot", {
        draggable: true,
      })
        .bindTwoWay("location", "location", go.Point.parse, go.Point.stringify)
        .add(
          new go.Shape("RoundedRectangle", {
            strokeWidth: 0,
            fill: "white",
            portId: "",
            fromLinkable: true,
            toLinkable: true,
            desiredSize: new go.Size(100, 100),
          }).bind("fill", "color"),
          new go.TextBlock({
            name: 'TextBlock',
            margin: 8,
            font: "bold 14px sans-serif",
            stroke: "#333",
            text: "Text",
            visible: false,
            editable: true
          })
        )

      diagram.nodeTemplate = nodeTemplate;

      const nodes = [
        {
          key: "N1",
          text: "Alpha",
          color: "lightblue",
          location: "100 100",
        },
      ];

      const links = [];
      diagram.model = new go.GraphLinksModel(nodes, links);
      setTimeout(() => {
        const node = diagram.findNodeForData(nodes[0]);
        console.log('Node.getDocumentBounds', node.getDocumentBounds());
        const textBlock = node.findObject('TextBlock'); // findObject returns null
        console.log('TextBlock.getDocumentBounds', textBlock.getDocumentBounds());
        console.log('TextBlock.getDocumentBounds', textBlock.getDocumentBounds());
        textBlock.visible = true;
        console.log('TextBlock.getDocumentBounds', textBlock.getDocumentBounds());
      })
    </script>
  </body>
</html>
8

That’s what I was saying earlier – the bounds of a not visible GraphObject might not make sense.

If you set visible: true (or don’t set visible at all), do you get sensible results?

9

The problem is that I want it to be invisible until text edition starts (to avoid visual artifacts of an empty textblock). But when the text block isn’t visible the TextEditingTool positions the text input in some random location because getDocumentBounds doesn’t return actual document bounds. Even if I make it visible in a custom TextEditingTool before calling super.doActivate then super.doActivate still sees {x: 0, y: 0}. Only after I add some text and make it visible it will start returning correct coordinates. For an invisible, empty TextBlock I would even expect {width:0, height:0} but not {x:0, y: 0}.

10

So you have a custom TextEditingTool that is deciding where to place the text editor. Can you look at the TextBlock and check the value of calling isVisibleObject? GraphObject | GoJS API

If it’s true, then use the normal / default positioning of the text editor.

If it’s false, then compute where you want it to be based on the Panel/Part/Node that it is in.

11

Thanks, I’ve started using the isVisibleObject function, and I’ve implemented a fallback to position the text area in the center of the containing part if the text block isn’t visible.