Sortable: Draggable animation grabs pixels of element above it

[tscizzle]

Searched the issues and don't see this one already.

The dark rectangles are the draggable elements.

Notice that the orange paragraph above has a piece of it dragging around.

And then when dragging the bottom one, it grabs a piece of the draggable element (dark rectangle) above it.

I don't have a jsbin of it, just curious if the developers, or any other users, have seen this before. Seems pretty recognizable, if it has indeed ever happened before.

[zanedev]

Yeah I'm seeing it. Not sure what the solution is yet. Seems to be related to css positioning. Will post back if I figure it out.

[stguitar]

I am also seeing this issue.

[zanedev]

So I fixed it by removing or tweaking the values for any absolute positioned elements inside the draggable item. If you have absolutely positioned elements with borders it causes issues.

[stguitar]

i have also since resolved my issue but i am doing this within the context of material design and angular 5. my issue was having the draggable element to have the 'matRipple' css class, which must be doing something similar to what you found.

in the end, i didnt need that class for my use case anyway so I simply removed it.

[tscizzle]

Hmm, I have a list of draggable items that exhibits this same behavior, but doesn't have any absolute positioned elements in it. So I think there's at least another thing at play.

[zanedev]

Yeah turns out I'm still seeing it so it's not directly related to what I
thought. The only consistent thing I've noticed is if the element you
start the drag shifts content around it or in some way overlays another
element too fast when the drag starts then it picks up whatever it shifted
over like a mirror copy of the edge. So most likely it's some render
related bug with the browser engine. Next, I'm going to try some tricks
that usually fix things like translate-z etc.

[zanedev]

I'm on Mac chrome btw haven't tried other browsers yet..

[markjanzer]

I had this same error on Chrome (but not on FireFox). There was an element absolutely positioned inside of the draggable element with visibility: hidden; that was forcing the ghost element to render larger than necessary. I solved it by setting the max-height of the absolutely positioned element to 0 when it is not visible.

[zanedev]

I fixed it for our use case by using forceFallBack: true which isn't ideal but works for now. There is a drawback to forcing the fallback however, I noticed that the positioning/offset of the dragged item from the mouse can get off slightly in certain situations.

I'm pretty sure this is a chrome bug, apparently whatever you are dragging using the native drag and drop apis needs to be completely visible in the browser with nothing covering it.

[indreksiitan]

I'm experiencing the same problem. But it only appears on Safari (11.0.3) on a Mac - Chrome (65.0.3325.162) and Firefox (58.0.2) on exactly the same site are OK.

[alexblunck]

The issue came up when upgrading from sortable 1.6.1 -> 1.7.0 & only appeared in Chrome 64+

I managed to fix it by setting position & transform on the sortable elements

position: relative;
transform: translateZ(0);

[indreksiitan]

In my case (1.7.0, Safari) it unfortunately doesn't seem to help.

[alexbainbridge]

I have used this on a list that includes a series of embedded dynamic maps (that have many absolute positions to make them work)

.sortable-chosen, .sortable-chosen.sortable-ghost { z-index: 10000; } .sortable-ghost { background-color: rgba(254, 245, 204, 0.35); }

Which at least hides the extra pixels (z-index) and the colouring of where you will "land" the item being dragged helps users know when to let go.

However my remaining problem is that the pointer calculates the centre including the hidden (extra) content.... i.e. off centre by a long way. However, progress :)

[Above works better on Chrome]

[zanedev]

@alexblunck's fix worked for me, much better solution than force fallback

[indreksiitan]

Ran into this issue again and now at least figured out what happens. The draggable row has icon buttons, which in turn have tooltips on hover. On Safari, the ghost dimensions are calculated with the tooltips shown, so it grabs some extra from above.

[indreksiitan]

.. and with the help of @markjanzer comment from Feb 6 now solved it with:

[data-tooltip]:after { max-height: 0; } max-height: inherit; }

[owen-m1]

Solved in 1.8.0-rc1 using @alexblunck's solution

[SysuCai]

This solution doesn't work on chrome 47