Resize node with enabled GridSnapper results in out of synch mouse pointer

[ivy-lli]

Hi all,
I just recognized that if you try to resize a node and you have the GridSnapper enabled the behavior is really strange because the mouse pointer will get out of sync with the resize handle.

With GridSnapper:

Without GridSnapper:

Sadly you the move cursor is not really visible here in the gif files but you can see the final cursor positions.

Reproduce:

• Enable the resizeFeature on the workflow-glsp examples TaskNode:
  • Open the glsp-client/examples/workflow-glsp/src/di.config.ts and remove the modelHintModule
  • Open the glsp-client/examples/workflow-glsp/src/model.ts and add the resizeFeature to the TaskNode DEFAULT_FEATURES
• Start the glsp-workflow standalone demo

To disable the GridSnapper, I just removed the binding of it inside the di.config.ts file.

Tested in Chrome and Firefox.

Kind regards

Lukas

[ivy-lli]

I think it has something to do with the DragAwareMouseListener. Because in the ChangeBoundsListener#mouseMove method is always the element which is currently hovered as target. This would result in wrong calculations of the GridSnapper if this one uses e.g the element.bounds to check the snapping. You can also see this if you move your cursor very slowly while resizing the element. If you do so the behaviour seems to be correct.

But this is only a guess 🙂

[planger]

It may be helpful for debugging to disable the CSS rule that hides the mouse pointer. I think I remember that @martin-fleck-at already mentioned an issue in this matter, which was the reason why the mouse pointer is set to none in the first place, but I don't know the details anymore.

[planger]

Now when I try to remember a bit more, I think this was a conceptual issue with the snapper.
If the user moves the mouse three pixels up, the snapper prevents the resize handle to move up, because it didn't snap yet. If -- after moving up three pixels -- the user moves the mouse down, we start counting from 0 before the snap happens, instead of starting to count from -3. Otherwise the user would have to move ~ 13 pixels before the snap happens, which felt weird at the time this was written. But I might be wrong.

[martin-fleck-at]

@ivy-lli Hi, you are absolutely right in that this is a bit of an usual behavior. For reasons that Philip mentioned already we initially chose another approach and decided to hide the mouse pointer to avoid confusion. However, the more common solution seems to be to properly consider the snapped position and ensure that the mouse pointer and the resize handle are in sync. I opened a PR to fix that with eclipse-glsp/glsp-client#144:

The nice thing is that now we can also show proper cursor feedback for moving and resizing.

[martin-fleck-at]

@ivy-lli I'm closing this task for now since the PR has been merged. If you have any follow-up issues please let us know. Thank you!

[ivy-lli]

Hi @martin-fleck-at,
Thanks for your fix, looks great! 🙂