Beholder4096

Same problem here, was looking at firstChild instead of firstElementChild. Problem solved, partially thanks to this thread.

So in the end I've decided to side-step this issue and pretty much work around it by putting the label onto the object itself. That way the label will move with the object and I will have to make a clone of the object if I want to "put it elsewhere" (and return this one with label to its original place). It's not much more work but it's pretty much guaranteed to work as I need without unnecessary hiccups. If I find anything that doesn't work according to what I think it should, I will make another minimal demo that you like so much. It's also my preferred way of unobfuscating problems and learning that way.

Oh, please don't be insulted, I am just trying to be more funny in this dry and totally logical work.. Will Ferrell is my favorite, as well as this clip. But I understand this is your work and if you want me be 100% here on the logical/dry side, I am all for it, no big deal. I am sorry and I apologize for my behavior and that it felt like nuisance to you. I guess I kind of found it funny that I come up with these weird bugs in the weirdest circumstances. Yes, this boils down to "should onClick be called after a drag was forced with .startDrag() when user clicked different element / and there was no actual drag?". Take it from UI design point of view: imagine the yellow element as transparent label with just label text. Imagine the green box as an image of an actual thing. User can to click OR drag the image even if they click/drag on the label. I want the draggable object stay behind the label since if there is no Javascript, user can still rely on the label / submit button and submit the page with the proper action. I modified the CP example to better convey what I am describing here. In the end, this probably cannot be categorized as a 'bug' but it quite certainly is an inconsistency. The green object can be dragged through the yellow label yet it cannot be "clicked through it". The green object can be clicked but not the very 1st time, when the draggable is being created, again on that time it can only be dragged. After that it can be clicked anytime. The cursor from this standpoint is also inconsistent: it changes to grab-hand when green object is dragged directly but never changes to grab-hand when green object is dragged via the yellow label. Or grab the green box and dragging it, move cursor slowly over the yellow label. If the cursor is an indication of an action that is currently going on (drag) then why would it change if the drag never ended? These inconsistencies are what I am after (to remove). Thanks a lot for looking into this. It seems like a small thing but I believe that by ironing out these inconsistencies your software will be accessible to wider array of less experienced developers. I know what I am talking about, I found these problems very early in my Draggable / touch learning experience and it bogged me down for a few days before I realized that I might be doing nothing wrong and where the problem might be.

Hey guys, it's Beholder4096, back again with another obscure bug. This time, the mind-boggling infestation here has taken me to discover two possible ways this bug can be demonstrated, so please bear with me.. I have an object (green in the CP example) which I need to make draggable, after user clicks another object, that is overlapping it (yellow in the example). When the overlapping yellow box on top is clicked, the draggable instance of green is created and green becomes draggable. So far so good. However, if I rerun the example and click the yellow and hold mouse button without movement and then release, the onClick of the draggable object doesn't fire! (all other events do fire, even onDragEnd() even though we were not dragging). I know it looks like it's for obvious reason.. But this behavior makes UI extremely inconsistent in my use case where I am very depending on this to work! Here the user can either (1) click the yellow overlapping object and release immediately (and the green object runs the onClick as it should) or the user can (2) click the yellow, hold the mouse for dragging and drag the green object to the destination. I have noticed that the exact same bug happens when clicking ONLY green object and releasing it without movement, but only when the Draggable.create() code is in the inline javascript onmousedown event. Please refer to the CP example where I have implemented both ways the bug can show. I must stress all of the other draggable events run ok, even the onPress event, which is also quite illogical since when I click the yellow box I never pressed on the green. And in the case of inline-js, I literally click the green and onPress registers but onClick doesn't work. While onDragEnd fires as well even though I totally didn't drag, just clicked. Aah, these crazy bugs, how come no one ever notices them? Please, PLEASE fix this as I would have to do a super-crazy workaround if the 2-box overapping scenario didn't work as it should. tl/dr: Click yellow box or green box. Do not drag. What happens: pretty much nothing, just draggable element gets to the front. What is expected: the onClick event of the draggable green box should fire and show alert.

Actually, I have realized there are no more issues. The ones that I had after this I was able to sort out myself. Thank you again for your support. I might have an interesting suggestion or two later but I need time to think them through and prepare test cases.

yes, that's what I was doing, you're right. I reported earlier. Our posts crossed. Thank you. 1 more unrelated issue, will post in another thread.

Actually no, it also seems to be a small bug in my own implementation, since kill() removes the object's Draggable instance from lookup table, I cannot find it and then I recreate the draggable instead of just enabling it. It is the Draggable.create() on the old object that causes the same bug, just as I reported earlier. I will also fix this in my code somehow.

Hmm, .kill() still allows the same bug to return from the dead. Other than that, works really nice, thank you! One more possible bug to solve (will post in another thread) and I can finally move to normal development.

I never got the link to the new beta version, am I missing something? Do you have some kind of repo I don't know about?

Yep, I confirm, I figured it out completely: The same bug you already fixed happens when you .disable() and then .enable() the already created draggable instance on the object (while holding the mouse button of course and then releasing it over the object). Also, it's the same thing with .kill(). Here is the pen https://codepen.io/Beholder4096/pen/PoRbZay In my case it is even more special, I basically call Draggable.make(oObj) on the same oObj multiple times because I remove the object from the DOM very soon anyway, so it pretty much doesn't matter (although it's not nice and I have to do something about it). This also causes the same behavior, along with creation of additional Draggable's listeners that are already present for the oObj anyway. Thanks for looking into this so extensively.This bug represents a kind of anomalous behavior that makes the draggable objects a bit more unpredictable, if nothing else. So I believe it should be fixed, although it can be quite easily prevented with a workaround.

exactly, it's the test case I made you, so I know how it works. Your testing/methodology was fine, your fix seems to work on the code pen. But when I try to load your file (or the code pen file) into my site, it loads but there is still no fix. And assuming this problem is trivial to set up and that I can check my own code for not making an obvious mistake of some kind, there must be some kind of problem still in your code that doesn't work here although it may in the pen. I also tried to compare differences between old 3.11.0 and the new 3.11.0 but there are many and since the code is practically obfuscated, it would be very difficult to check for this particular difference and see what is going on in there. I must go to get at least a nap myself, I will leave the site on for you so go ahead and check it out anytime you want. I also see I must do something about calling Draggable.create() with an element that already has an instance, because an additional click listener is being piled on that element by each additional Draggable.create(). It didn't matter so far because I was working on reporting those bugs, but today I must do something about it already.

basically you can just toss the cards by doing upward drag, they will release from mouse by themselves. Releasing the mouse on a tossed card still shows the problematic behavior (with the correct file I think, forced those links as well).

nope, I think I have the correct file loaded; I have modified it by a small mark on top of the file and see that same mark in the dev tools, so it's not working as intended here.. I have rechecked my implementation and it seems fine, should work like the code pen but it does not. The onclick fires on the release consistently. I can give you the site and you can immediately see for yourself if you want.

Hmm, actually no. Seems to work exactly as before: the onClick fired when "cancelled" drag was released over the previously dragged element. When we cancel the drag, we want to help the user by lifting the virtual finger from screen/mouse. As for the "extremely" uncommon case, imagine a stack of cards and you want to use your mouse to frantically "toss" them one by one from the stack. Similar to tossing dollar bills from hand onto strippers by placing the bills on one hand and tossing the individual bills one by one with another hand in a quick succession. I also preemptively cancel the dragging of the object mid-way and help the user by finishing the drag by animation: it is very responsive and quite natural. But INEVITABLY it will happen, that you will release your click on a card that is currently either animating or is being tossed already after animation. And then the onclick will happen which runs an unwanted action. I could do workarounds but why would an onclick happen after a release, not after press+release only? I guess this is more of a philosophical than programming issue though.

Hmm, I originally thought that these things must be really completely set to standards, otherwise sh!t would just break.. oh well, here we are.. I also never asked you about those weird sizes of the inner box which actually affected this bug. 200x200px was not working properly [endDrag() not properly ending the touch], while 100x100px was working pretty much all the time. How come? some more mobile/browser quirks?