GLSP V2.3 - graph is not rendered - translate(NaN,NaN)"

[rsoika]

I have made a very very strange observation during migrating from GLSP 2.1 to 2.3. It is hard to describe and to reproduce:

In my Open-BPMN Project I build the GGraph from my BPMN (XML) source file. I have had a very old diagram that did not open. All other diagrams work normal with version 2.3 so far.
So I tried to isolate the problem and I was able to reduce the problem diagram to at least 3 elements causing the problem. In glsp 2.1 the diagram shows like this:

In glsp 2.3 it does not show any elements. So I tried to figure out which of the elements causes the problem. Removing one of the elements all is good again. Only with this 3 elements the problem occurs. The problematic coordinate seems to be the Y-Position of my task element, which is 209.0 . Changing this value to any other value fixed the problem too!.

In case of the problem situation, the diagram did not show any element.

After I inspected the graph element (Theia), I can see that some parameters are 'NaN' !

In the javascript console I see this message

attributes.ts:33 Error: <g> attribute transform: Expected number, "…le(1) translate(NaN,NaN)".

Here is the full console.log: localhost-1739618734016.log

This all does not look to me that I have something bad in my own code. I have also a 'Auto-Align' Feature in Open-BPMN. This snapps all elements into a 10x10 grid. Calling this command, saving the model and reopen it, fixes the problem (because the y-coordinate adjusted to 210.0

Very very strange.......

[tortmayr]

Hi @rsoika ,
Unfortunately I cannot reproduce this behavior with our dev example.
If I recall correctly you have a public access deployment of the OpenBPMN editor.
Could you maybe provide an example that we could test/debug there?

[rsoika]

Hi @tortmayr,
good news - also this error is now gone. The bug was caused by my own custom implementation of the BPMN Manhattan router. During migration to GLSP v2.3 I refactored the complete implementation. The result is a better and bugfree behavior.

You can test Open-BPMN online here: https://open-bpmn.imixs.org/#/home/node/app/open-bpmn.glsp-client/workspace

And you can find the new Implementation of the BPMN Manhattan Router here: https://github.com/imixs/open-bpmn/blob/master/open-bpmn.glsp-client/open-bpmn-glsp/src/bpmn-manhattan-router.tsx

The new concept (with is now very simple) is the following. The router stores the last routings of an element onclick. The route computed by the origin implementation is ajusted only in the way, that the first/last waypoint is treated as fixed and the docking point is computed based on the position of this waypoint. As a result the docking point is no longer floating around the border of the element and stays fixed at the position is was placed by the user. For BPMN model this provides a more natural routing behavior. It may be unnecessary for other model cases.