"Preview" of item during drag not visible - Chrome 50 on Mac

[mattheworres]

I recently worked on integrating your library into my project while on the Windows side of my machine - developing mainly on Chrome and Firefox. Both seemed to handle the library the same, which was great.

The feature is mostly done (hooray), and I went to check and see how it ran on the Mac OSX side of my machine. Firefox runs it great (I think the Mac implementation of the HTML5 spec is better - the "preview" of the draggable object on Mac is much better), and the latest version of Safari worked flawlessly as well.

The issue I saw started on Chrome 49. The "preview item", which on Mac ends up being a transparent drawing of the entire draggable object, ends up getting drawn to the left of the mouse cursor (on Firefox and Safari, it's drawn under the cursor according to where I grabbed it). After testing a little while, I noticed that depending on how close to the left-most pixel of the draggable I grabbed it with (so starting at an X of 0), the closer it was to the cursor (but the right-most boundary was still at least 20 pixels to the left of my cursor). So if I grabbed closest to the right-most boundary, it would be probably 200 pixels to the left of my cursor.

I noticed the latest Chrome you tested for 1.4 was 48, and decided to perhaps test 50 -- so I updated. Now Chrome won't even draw the preview object. The good news is that everything else (drag events, classes, etc.) all works perfectly and the library performs as needed, so this is only cosmetic.

I tested the demo site and did not see this issue there either. If it would be helpful I can put together a quick test site on OpenShift as the project I'm working on is an open source one, and then you can take a look yourself.

[mattheworres]

Here's a link to the page in my app that shows the issue - on any modern browser in Windows, everything works as expected (as far as I could tell), but Chrome on Mac does not (even Safari worked well):

http://phpdraft-mattheworres.rhcloud.com/draft/3/depth_chart

The cells of "picks" at the top of the depth charts are the draggable item, and the positions make up all the different lists. As long as a draft is still ongoing the depth charts are still draggable.

[zhipengyan]

I drag item with pure ReactJS without using this lib in my app , but I have the same problem after upgrade chrome to 50 on Mac OSX. You should set the div element attribute 'draggable' to true.
<div class="pick selected pickRB" draggable="true"... >...</div>
@mattheworres

[mattheworres]

@zhipengyan perfect! I figured it was something related to the HTML5 spec that Chrome was probably ahead of the game on. I bet as time goes on there's a good chance other browser vendors will adopt this as well. Nice!

[mattheworres]

@marceljuenemann this

place a draggable="true HTML attribute on elements with dnd-draggable directives in order to make dragging work on Chrome 50+

should probably be put somewhere in the README (I'd gladly open a PR to do so for you) but not quite sure where it makes sense to do so. Any ideas? As more folk upgrade their Chrome browsers, they'll probably see this as well.

The more I think of it, the more it seems like a bug that the library could remedy by adding to the element itself. If I have time I'll open a PR.

[didi3r]

Adding draggable="true" doesn't solve the problem for me, my html markup is something like this:

<li dnd-draggable=".." .... draggable="true">
    <dnd-nodrag draggable="true"> <! -- draggable attr added by the directive -->
        <div draggable="true">
            <span dnd-handle draggable="true">:::</span> <! -- draggable attr added by the directive -->
            ...

        </div>
    </dnd-nodrag>
</li>

If I remove the dnd-nodrag and dnd-handle elements the drag image is displayed correctly, but of course, I only want to be able to drag the whole <li> from an specific handle.

[vytant]

I figured out that Chrome hides child elements with position: relative; CSS property. You can try to remove position: relative; or set it to position: static; but it will affect your elements style.
So it's caused by Chrome bug, not library it self.

[cp]

For me, even setting position: static or removing position: relative; didn't work. The solution I used was applying -webkit-transform: translateZ(0);, which forces Chrome to use hardware acceleration. Anyone else tried this?

[tfvictorino]

For me, applying draggable="true" to the <li> didn't work. Applying it to the element inside the <li> (the one with visual properties) worked, though.

[jaymanned]

Hi I had the same issue as @tfvictorino and applied the same workaround successfully. I'm a bit concerned though about this story. @mattheworres how did you find out about the draggable="true" workaround?

[N1kto]

Indeed that's a bug of Chromium introduced in Chrome 50 release. They changed the way ghost image is prepared by browser.

They claim to have it fixed. Workarounds that work:

1. position:relative; z-index:0;
2. transform:translateZ(0);
3. will-change: transform;

[Deklin]

@N1kto where should those styles be applied?

[N1kto]

@Deklin to the DOM element you want to drag. Of course, you don't have to apply ALL of the listed styles. Any of those will work - it's just a matter of case/choice.
I think the safest is option 2, since it doesn't require you have a position: relative and it is widely supported (comparing to will-change).

[mattheworres]

I think I'm going to close this as it's mostly an issue in Chrome, and one that they have purported to have fixed.

[Deklin]

@N1kto Thanks, unfortunately no luck but if Chrome is going to be fixed, we'll wait it out.