Bugs with LayeredDigraphLayouts?


I’m writing to the forum because we are out of the ideas how to fix issues we see with GoJS (possibly).

Now I’ve made a little snippet, a very simplified version of what we are dealing with:


We are using GoJS 1.7, which is kind of outdated, so we though about maybe switching to the 2.1 (latest) version, but as far as I can see, we have the same problems. So I thought maybe we are doing something wrong.

Layout for Diagram and Group templates are go.LayeredDigraphLayout.

I made sure, that scenarios which I will describe below, will always reproduce the bugs, but additionally I will include screen-casts.


Diagram layout isOnGoing = false
Groups layout isOnGoing = false

1st bug?:

Scenario 1:

  1. Open G2
  2. Open G5
  3. Open G3
  4. Move G3 slightly to right
  5. Open G7

Result: W12 is outside of the group G7.


Scenario 2:

  1. Open G3.
  2. Move G3 slightly to right.
  3. Open G7.

Result: W12 is outside of the group G7.


2nd bug?:

  1. Open G3.

Result: link between W6 and W9 is broken. Is not fixed until user moves W6 or W9.


Diagram layout isOnGoing = true
Groups layout isOnGoing = true

1st and 2nd bugs are gone.

bug 3?:

  1. Open G3.
  2. Open G7.
  3. Click and drag W12 slightly to the right.

Result: G3 and G7 groups are “flashing” while dragging W12 to sides.


bug 4?:

  1. Open G3.
  2. Open G7.
  3. Move G7 to the left and release once group is starting to resize drastically.

Result: link between W10 and W11 appear in the wrong place.



In most cases problems are with nested groups…

Are we doing something wrong? Or these are the bugs from GoJS?

We, by default turn off auto layouts, because users were complaining about “suddently widget is gone(out of view)” when drag & dropping from palette, as the layout tries to arrange and moves dragged in node to the far right. As we have, in some cases, huge diagrams, we let out users to arrange their nodes however they like, but we have button for auto-layout, which calls layout.doLayout() with the selection as an option.

Hmmm, this will require some investigation. Thanks for providing a detailed write-up.

The first thing that you can do in the meantime is set Layout.isRealtime to false. That will avoid some of the bad interaction between changing the size of groups while layouts are happening during a drag.

Another thing to try in the first scenario with Layout.isOngoing false, is to set Group.computesBoundsIncludingLinks to false.

But even with these improvements, there are still some problems…

Thanks for reply,

As I mentioned in my comment, we want to keep Layout.isOngoing false, as this allows users to arrange nodes however they like and have an option to auto-layout diagram.

I’ve tried out your suggestions and yes, there are still some problems.

Having Group.computesBoundsIncludingLinks set to false, fixed the 1st bug (nodes now appear in the groups.

Having Layout.isRealtime set to false, fixed 3rd and 4th bugs.

However, link still appear “broken” in the 2nd bug.

Are you even considering fixing this bug and how much time do you expect it would take?

Actually we have already spent a good bit of time looking into it, but we don’t have an estimate yet for when we can fix it.

Could you please try the 2.1.31 beta that is at https://gojs.net/beta ? You can just grab a copy of the https://gojs.net/beta/release/go.js or go-debug.js file.

By the way, the bug has nothing to do with LayeredDigraphLayout.

Thanks for the effort,

Yes, I agree that it has nothing to do with the LayeredDigraphLayout, because yesterday I have tried TreeLayout and saw similar problems.

I have just fired up the same fiddle and loaded the beta version. Unfortunately, the result has not changed.

It depends on Group.computesBoundsIncludingLinks set to false.

Thanks for the reply,

Ok, I’ve added Group.computesBoundsIncludingLinks and set it to false, but there are still problems.

Let me show you a screen cast from our development version and from the updated fiddle.

Development version:


Updated fiddle:

In the fiddle you can clearly see the problem with links, which we have in the development version. It takes very strange routes… (You can reproduce the same behavior every single time, if you take the same steps as in the screen cast).

In all cases, the problem occurs when you move a Node or a Group and it is linked with this “artificial” Link, which GoJS shows it connected to the outer Group even if its connected to the Group inner Node.

Thanks! We’ll investigate further.

Could you please try again with the latest beta library?

I’ve tried with the latest beta and the problem is partly fixed.

I was unable to reproduce broken links from the last comment, which points to nowhere.

Now we only have a problem with the strange Link routing, which can be seen in the last comment or in this image:

Now I though about, what is common between all these 3 links… They are all on the same level, what I mean by the same level - the Link which has wrong routing links 2 Nodes, which are in the same depth (same Group). If user moves collapsed Group, then expands it the links always have this bizarre routing.

And I can reproduce the exact same problem in the fiddle from the last comment (https://jsfiddle.net/q5a72dg0/6/).


  1. Open G3.
  2. Open G7.
  3. Close G3.
  4. Move G3 around G2 in a circle.
  5. Open G3.

Result: Link between W6 and W9, and link between W10 and W11 has a wrong routing.



Could you try the very latest beta now, please?

It’s interesting that you have discovered a combination of features that had several bugs. Thanks for telling us about them and creating those Fiddles.

Thank you Walter, I have tried the beta and as far as I can see, issues were resolved. I couldn’t reproduce any of the bugs.

When are you releasing version with the bug fixes?

Soon, I hope.

Hello again,

so I accidentally stumbled across another issue with the expand/collapse feature - bug. Now it’s related to the animation somehow.

If a user after clicking on the SubGraphExpanderButton clicks on the group, which is being expand or collapsed, suddenly the inner contents of the group appear in the wrong places and the bizarre behavior of links is back.

I took the same fiddle:

aaand did what I have described.

Look at the result:


I presume the animation fails to jump to the last state, if a user has interacted with the node while it is being shown.

Yes, that seems to be what’s happening. Starting a transaction will automatically stop any ongoing default animation, such as the subgraph expansion. We’re looking into it.

For now, I suppose you could decrease the AnimationManager.duration to make it less likely that can happen.

Could you please try the new beta 2.1.32 ?

Bugfix seems to be working.