React-dnd: Wrong dragPreview in Chrome

@tTwisTt I'm facing this exactly issue, did you figure out the fix?

@kaiomagalhaes In my case I was getting this issue due one of child element of row (cell content) in fact had height that was greater than row height, but was hidden by visibility: hidden in css. So dragSource had width of rows and height of hidden control. I hope you'll find this helpful.

@tTwisTt I can confirm that, same happens with overflow: hidden. is there a way to drag elements like these without the wrong preview?

This issue is closed, but it seems to still be a issue, shouldn't it be reopened?

I also have this same issue - when I start dragging the preview is too large and does not respect parts which should be hidden by overflow.
Here you can see how I drag an element but the "border" left next to it is part of the preview as well.

EDIT: I was able to fix it by not using a relative positioned image in the element but instead a div with a background image instead.
So it seems the inner img element reaching out of the parent caused the problem.

I experienced a similar issue when I try and drag a div wrapped material ui Expansion Panel that is collapsed, it ends up giving me a preview that is the height of the panel expanded but includes elements from the page around the panel, since the visible portion of the panel is smaller than the preview.

i resolved this issue on chrome by adding transform: translate3d(0, 0, 0) to my containing element.

@RahulRameshNarayan this also worked for me. THANK YOU!
Any idea why this fixes the issue??

@jsyvino its a repaint issue on chrome. translate3d forces better hardware acceleration on that element. This is also a hack that people use to solve flickering of scrolling elements in screens of higher resolutions. you can read further about this topics in the following articles.

Let's Play With Hardware-Accelerated CSS-
https://www.smashingmagazine.com/2012/06/play-with-hardware-accelerated-css/

Accelerated Rendering in Chrome
https://www.html5rocks.com/en/tutorials/speed/layers/

Simplify Paint Complexity and Reduce Paint Areas
https://developers.google.com/web/fundamentals/performance/rendering/simplify-paint-complexity-and-reduce-paint-areas

transform3d(0,0,0) fixes issue of whole page screenshot but has wrong position of an element.

This problem is only on chromium based browsers.
Did anyone had similar issues and how did you fix it?

I'm also getting this issue on Chrome 75 when using a Material-UI ListItem as the draggable node. I think the Ripple element that is contained by overflow: hidden is what's causing the sizing mismatch.

As @makr11 mentions, @RahulRameshNarayan's fix does somehow solve this (by hiding the surrounding elements from the drag preview, seemingly), it does still have the position offset that it would as if those elements were visible, so it's still 'broken' in my opinion.

Does anyone understand what the underlying issue is here, seemingly at the DOM or Native/HTML5 drag preview generation level maybe? Would love to tackle fixing this properly.

Same here, i'm getting this issue on Chrome 75, on Firefox works fine... This should be reopened!

My use case is specific but maybe it will help someone, I use velocity-dashboard which uses react-dnd, and inside widgets (which is a draggable component) is rendered react-chart-js. The problem happened when chart-js was rendered inside widget. I just set that when widget is draggable, basic div is rendered inside widget and not chart-js component.

Again, it's pretty specific and i'm not an expert for the subject but maybe this will help someone.

Issue still reproduced (Chrome 75.0.3770.100 )but resolves by adding transform: translate3d(0) to contain element. Thanks @RahulRameshNarayan

I'm also experiencing the same trouble. I tried to solve it by adding transform: translate3d(0, 0, 0), but have the same issue as @makr11 here: https://github.com/react-dnd/react-dnd/issues/832#issuecomment-501292272

Issue is still presence in the:
Safari 13.0.1
Chrome 80

transform: translate3d(0, 0, 0) helps, but can affect on other styles/elements in your interface.

@mismith I am struggling with exactly this problem (also using MUI ListItem), did you come up with a solution?

@dotbear Sadly no, I am just living with it :(

I agree this issue should not be closed without an official workaround that avoids the giant offset problem.

Any news refering to this problem?