Debug tips for "locked" nodes

Hi, I’m running into some weirdness that I am at a loss how to debug…

Since each diagram operation needs to go to the server, we have built a pretty complex / intricate copy/paste undo/redo mechanism, to keep everything in sync between gojs, angular and server.

Weirdness started happening after upgrade from 2.3.2 → 2.3.16, but also gojs-angular from v1 to v2 (which i knew had breaking changes with the immutability, but those should have been taken care of).

Latest issue is demonstrated next:

  • I have a couple nodes in the “clipboard”, I paste it once (all good) and then paste it again.

Kapture 2024-03-27 at 14.52.59

Question is: why do the nodes get “locked” and how can i debug this? which node properties should I be looking at? I’ve tried requesting diagram update / redraw and a bunch of other things and nothing seems to work. The nodes that get locked depend on the ones I try to move, i.e.: if I try to move the first paste, the second paste gets locked and vice versa. All nodes have unique keys.

Normally the ability to move a node by the DraggingTool is controlled by the Part.movable property. You can ask about a Node’s movability by calling Part.canMove. Read more at: GoJS User Permissions -- Northwoods Software

It is also possible to affect the dragging behavior for specific Parts by setting their Part.dragComputation or overriding methods on DraggingTool, but those involve more thought and effort.

So which of these things have you set/bound/overridden? GoJS User Permissions -- Northwoods Software

I’ve just checked the Part.canMove() on the nodes and even the ones that are “locked” return true. I am setting/overriding the Part.dragComputation but for nodes within groupboxes, so the example above that method returns the new point pretty much immediately.

DraggingTool is using the example to show the guidelines - we’re not blocking any movements there…

I skimmed through the other user permissions and they seem to be diagram wide, so that’s not it either. And besides, as I mentioned, if I move the top left nodes first it’s the bottom right nodes that get locked - so I don’t think it’s any specific permission because I’m not changing those by just dragging a node. Also, this started happening after the library upgrades - wasn’t an issue before

Any other ideas where I could look? thanks

Check your Node.dragComputation function to see what it’s returning in the “locked” case.

Screenshot 2024-03-27 at 15.51.43

it returns a new point, and apparently it “moves” with the mouse, but not on the diagram.

I found this fork of the gojs-angular library (@newzdhong/gojs-angular) which allowed me to test the v1 library again (your v1 doesn’t support angular 17) and I tried it, as well as reverting the core gojs library. the issue is not exactly the same but still happens. Randomly, nodes get “locked” or sometimes they move, but the links that are attached to them don’t follow.

after refreshing the page everything is perfect, so issue is only after pasting (multiple times it seems).

Is there no way to force refresh the diagram from the model or the model from the diagram? I believe I could completely wipe it out and render it again but that would invalidate the undo stack…

If you downgrade GoJS from 2.3.16 to 2.3.2 (or whatever the old version was), without changing the version of anything else, do you still have this problem? I’m trying to narrow down whether it involves the specific GoJS version or not.

I didn’t test downgrading just the core library (i suspected the issue was with the gojs-angular) but our current production version doesn’t have that “locking” behavior, it does, however, have other issues, for example, if the paste includes groupboxes, some of the child nodes do not display on the second paste.

In the meantime it seems I’ve found a solution / workaround for this specific use case, which is: whereas the “redraw()” and “requestUpdate()” didn’t help, forcing a new model (diagramNodeData and diagramLinkData arrays) after the operations complete, did! And if I don’t “clear()” the diagram, I get to keep the undo stack.

I don’t think forcing the new model should be necessary, since, when adding the new nodes we already do it “immutable-ly” and using addNodeData and such…but it solves it for now.

We are doing a thorough round of testing after the library upgrades and this was not the first issue we found, just the one that made me bang my head the longer…testing continues so I’ll update this thread in the next couple of days.