Layouting issues/ visual glitches with client-side layouted nodes

[tortmayr]

Currently we seem to have a couple of minor bugs that cause glitches layouting issues when creating new nodes or clicking on existing nodes (e.g. label edit)

• When creating a new task node there is visual glitch on model update:
  After the server update the node brievly gets larger (the right side increases) and then is reset again

• When creating multiple nodes in a row the previously created task node sometimes increases in size

• Nodes cannot be created without an empty grid space between them. I.e creating a node directly below another node without leaving empty space is not allowed. I guess this is caused by the overlap/container check.
  But in theory this should be allowed, since the nodes are not overlapping, they just have 0 space between them

• Interacting with the node via click (e.g. edit label) sometime causes a visual resize

Here is a short demo:

layouting_issues.mp4

[tortmayr]

@martin-fleck-at I already had a short look into the related code and noticed that we trigger a LocalComputeBoundsAction on each click on a resizable element. (https://github.com/eclipse-glsp/glsp-client/blob/daca6812b3cac934626ea056b8f0ca17c2fb61f8/packages/client/src/features/tools/change-bounds/change-bounds-tool.ts#L211)

While its probably not the root cause for this issue it still seems unnecessary to me. To you recall why this was necessary/introduced in the first place?

• Just clicking activating a resize element should not require a bounds recomputation. The element size does not change, so
  the previous computed layout should be correct. We just add resize handles wich are excluded from bounds computation anyways
• We trigger a LocalRequestBounds action with every actual resize (i.e. SetBoundsAction during resize feedback) anyways so the layout should always be computed correctly
• Even if its necessary, we retrigger the behavor on each mouse down of the element even if the element is still active. (Resize handles are active, element is still tracking). I think we are missing a check here to avoid the behavior if the element is already active.

WDYT?

[martin-fleck-at]

@tortmayr So what you are saying is that we do one unnecessary local bounds computation when we select the element on click, right? The code you reference should only do it once because we immediately dispose the feedback again. Could it have something to do with an "external" selection change since this triggers the same code? Or maybe cursor and validation feedback (for overlapping etc.)? I do not fully remember but the comment seems to suggest that it was necessary at some point so we definitely should test different cases before we remove that code - especially if it is not the cause of the issues we are seeing.