[BUG] Message/Sequence Flow start and end points are sometimes not at the right position

[tbouffard]

Describe the bug
See what is expected (bpmn-js) and what we have with [email protected]

With the non regression visual tests BPMN diagram flows.message.01.icons.bpmn - on the message flows on the left of the diagram.

With the non regression visual tests BPMN diagram flows.message.02.labels.and.complex.paths.bpmn, we see that the zoom/scale factor (in the following, when clicking on 'Fit View') changes to position of the message flows
Notice that we also see issues

• with the position of the message flow arrow on the top right (same as [BUG] Association Flow arrow sometimes displayed inside the terminal BPMN element #715?)
• always orthogonal message flows segments ([BUG] Message/Sequence flow segments shouldn't always be orthogonal #295)

This also occurs with sequence flows, see rendering of C.6.0, the first (from the top) outgoing sequence flow from the Make Booking subprocess

Expected (from the miwg-test-suite reference png)	What bpmn-visualization displays

To Reproduce
Independent of the OS and the Browser.
The bpmn-js comparison example can be used to check the behaviour discrepancies.

Additional context
We have detected this issue on message flows from day 1, see #394.
The root cause may be the same as in #715: scaling computation issue.

[tbouffard]

The following animation done by loading the non regression visual tests BPMN diagram flows.message.01.icons.bpmn with [email protected] show that depending on the zoom/scale factor, the message flow on the left of the diagram is sometime displayed at the right or wrong position.
This can be reproduced in demo and test page of this repository, using Fit on load (whatever value it is) or no fit, the behaviour is the same.

This can also be reproduced with a simplified version of the test diagram (flows.message.01.icons_simplifiied.bpmn.txt) that only contains the fewest elements, showing that the rest of the diagram has no influence here.
The BPMN elements are perfectly correct (see the simplified diagram file content for instance).

[tbouffard]

Question: could this be related to what is described in jgraph/drawio#1872

Fix for segment connector routing differently at different zoom levels. The code section checked for result points being inside the source and targets, which have a non-trivial area for floating ports. The points in the results array are not scaled, the target and source being used were scaled, so contains was incorrect at specific zooms and removed points.

Seems fixed in jgraph/drawio@91c8890
Let's check if the SegmentConnector is involved here: https://github.com/jgraph/mxgraph/blob/v4.2.2/javascript/src/js/view/mxEdgeStyle.js#L592, if so the mxgraph change is located somewhere after jgraph/drawio@91c8890#diff-407d955a2d2bc1b027fb92faf205a498090549c93ee3b99274b3851cd0096d70R950

[tbouffard]

New changes in draw.io

https://github.com/jgraph/drawio/blob/v14.7.3/ChangeLog
29-MAY-2021: 14.7.3
Fixes rounding errors in segment connector [2257]
jgraph/drawio@82f74a0#diff-407d955a2d2bc1b027fb92faf205a498090549c93ee3b99274b3851cd0096d70

[tbouffard]

Root cause: when using segment connector (that produces orthogonal segments, #295), depending on the zoom level (i.e the mxgraph scale values), some points on the edge definitions are wrongly removed.

fix attempt based on draw.io reverse engineering: poc #1363

• does not work
• as we want to get rid of the segment connector ([BUG] Message/Sequence flow segments shouldn't always be orthogonal #295), I suggest we investigate time to be able to stop using the Segment Connector instead of trying to fix mxgraph.