bug(cdkDrag): using cdkDragConstrainPosition causes erratic behavior

[ma7moudat]

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

13.3.9

Description

cdkDrag works normally with box and axis constraints, but as soon as cdkDragConstrainPosition is used, the dragged element incorrectly jumps a few pixels down the y-axis.

Reproduction

Please refer to the reproduction:

https://angular-ivy-iry1fk.stackblitz.io

https://stackblitz.com/edit/angular-ivy-iry1fk?file=package.json

Expected Behavior

The dragged element should only move horizontally and not jump down the y-axis.

Actual Behavior

The element jumps a few pixels down.

Environment

• Angular: 14.0.0
• CDK/Material: 14.0.0
• Browser(s): Chrome / Firefox
• Operating System (e.g. Windows, macOS, Ubuntu): Windows

[crisbeto]

This is likely the result of #25061 which made it so that the position constrain function determines the top/left coordinates of the element. You see it jump down a little because the "normal" dragging behavior also accounts for the pick up position within the element whereas the one returned from the constrain callback is the top/left. This is how the constrain position input was intended to work, but a poorly written unit test meant that it had broken at some point and we hadn't noticed.

[mj3052]

I must admit that I at this point cannot figure out how to use the cdkDragConstrainPosition after #25061 was merged. We had a working implementation with the old behavior.

I understand that the given point is now where the mouse is dragging on the page, and just returning the point will make the element render with the top/left at exactly that point. But even if I just offset that by say 10px, it seems to make the whole drag/drop experience act weird.

Maybe it is just missing documentation / information about how one is expected to implement the constraining logic I'm missing, but to me, the old behavior was at least a bit more intuitive.

[ma7moudat]

This is likely the result of #25061 which made it so that the position constrain function determines the top/left coordinates of the element. You see it jump down a little because the "normal" dragging behavior also accounts for the pick up position within the element whereas the one returned from the constrain callback is the top/left. This is how the constrain position input was intended to work, but a poorly written unit test meant that it had broken at some point and we hadn't noticed.

Not sure I understand. Does that mean that it actually is a bug that needs fixing in cdkDrag? Or should I adjust my code to work with the new logic?

[crisbeto]

The idea of that function has always been that the Point it returns is where you want the top/left corner of the dragged element to be. It's how it worked when I initially introduced it, but it regressed at some point. There was a unit test for it, but it was poorly written so it didn't catch the regression.

[ma7moudat]

Ah okay! Thanks.
So if I understood correctly, it should work for me without the jumping if the Y of the returned point matches the getBoundingClientRect().top of the parent element (or the constraining element).

[ckorherr]

@crisbeto I have the same problem, basically I want to use it for a split view, so I lock the axis in one direction and also want to constrain the position in the other direction. This is now next to impossible and is preventing us from updating to Angular 14. With Angular 13 it worked perfectly.

This is a simple example showing the problem:
https://stackblitz.com/edit/angular-zsuwad-juyc6z?file=package.json,src%2Fapp%2Fcdk-drag-drop-axis-lock-example.html,src%2Fapp%2Fcdk-drag-drop-axis-lock-example.ts

With axes locked, the constraint causes erratic behavior.

[crisbeto]

So the (not well documented) assumption is that if you're using constrainPosition, you're in complete control over the positioning. lockAxis and boundary may end messing with it since they're all modifying the same coordinates and can end up returning conflicting information.

In retrospect, lockAxis and boundary should've been implemented as functions for constrainPosition that are provided by cdk/drag-drop.

[ckorherr]

Makes sense, I'll try that, thank you!

[ckorherr]

Works perfect.

[ioanes]

The idea of that function has always been that the Point it returns is where you want the top/left corner of the dragged element to be. It's how it worked when I initially introduced it, but it regressed at some point. There was a unit test for it, but it was poorly written so it didn't catch the regression.

Can you provide an example how to calcuate returning point coordinates so it will drag the item without jumping to top left corner? So basicply the constrainPosition function will not do anything. From that point we can adjust the code for our needs.

`constrainPosition(point: Point, dragRef: DragRef)
{

// calculate default beahviour. Move element from where you grab it.

return point;

}`

Thank you

[crisbeto]

You'd have to offset it based on the position at which the user picked up the element, which I now realize isn't possible to read. I've opened up #25341 to expose it within the constrainPosition callback.