marya

BTW sorry but this is my current demo that I'm testing with. I was messing around, trying to reproduce the issue, but if you have a device where you want to test this, this would be the new link with the logging statements in my own version of Draggable.

More info: I added another print statement just before if (clickTime !== clickDispatch && self.enabled() && !self.isPressed) { When there's no "two click" issue, clickTime is exactly identical to clickDispatch. For example, I see "1565801433538, 1565801433538." When there is a "two click" issue, clickTime and clickDispatch are different, e.g. "1565801437311, 1565801436128". I would be soooooper happy if you could make this issue go away, since then I think I could just use GreenSock Draggable work straight out of the box, and not have to rejig my framework; that is looking quite hairy right now. And this does seem to be a GreenSock issue, although I realize it is difficult to reproduce. (Just to be clear, it is easy to reproduce on the RCA Cambio that I'm testing on - usually I can click my demo less than 10 times, and the "two click" issue appears at least once.) I'd be very interested to know what you guys do to test your framework, and how many devices you test on, how much testing is manual vs automated and so on. If it's not secret sauce ?

More information: I added debug code to your open source version Draggable (not your most recent one, but rather the one from earlier this year, Version 0.17.1). It appears to me that the "two click" problem that I see on my touchscreen Win10 device occurs due to code in Draggable.onRelease. The code looks like this: if ((!_isAndroid || originalEvent.type !== "touchmove") && originalEvent.type.indexOf("cancel") === -1) { //to accommodate native scrolling on Android devices, we have to immediately call onRelease() on the first touchmove event, but that shouldn't trigger a "click". console.log("B1"); _dispatchEvent(self, "click", "onClick"); if (_getTime() - clickTime < 300) { _dispatchEvent(self, "doubleclick", "onDoubleClick"); } eventTarget = originalEvent.target || originalEvent.srcElement || target; //old IE uses srcElement clickTime = _getTime(); syntheticClick = function () { // some browsers (like Firefox) won't trust script-generated clicks, so if the user tries to click on a video to play it, for example, it simply won't work. Since a regular "click" event will most likely be generated anyway (one that has its isTrusted flag set to true), we must slightly delay our script-generated click so that the "real"/trusted one is prioritized. Remember, when there are duplicate events in quick succession, we suppress all but the first one. Some browsers don't even trigger the "real" one at all, so our synthetic one is a safety valve that ensures that no matter what, a click event does get dispatched. console.log("E1"); if (clickTime !== clickDispatch && self.enabled() && !self.isPressed) { if (eventTarget.click) { //some browsers (like mobile Safari) don't properly trigger the click event console.log("F1"); eventTarget.click(); } else if (_doc.createEvent) { syntheticEvent = _doc.createEvent("MouseEvents"); console.log("C1"); syntheticEvent.initMouseEvent("click", true, true, window, 1, self.pointerEvent.screenX, self.pointerEvent.screenY, self.pointerX, self.pointerY, false, false, false, false, 0, null); eventTarget.dispatchEvent(syntheticEvent); } } }; if (!_isAndroid && !originalEvent.defaultPrevented) { //iOS Safari requires the synthetic click to happen immediately or else it simply won't work, but Android doesn't play nice. console.log("D1 delayedCall"); TweenLite.delayedCall(0.00001, syntheticClick); //in addition to the iOS bug workaround, there's a Firefox issue with clicking on things like a video to play, so we must fake a click event in a slightly delayed fashion. Previously, we listened for the "click" event with "capture" false which solved the video-click-to-play issue, but it would allow the "click" event to be dispatched twice like if you were using a jQuery.click() because that was handled in the capture phase, thus we had to switch to the capture phase to avoid the double-dispatching, but do the delayed synthetic click. } } If you notice, I added some logging, but this is around line 2010 of the source. When there is no double click, I see B1, D1 delayedCall, and then E1 in the JavaScript console. When there is a double click, I see B1, D1 delayedCall, E1, then F1. Just so it's clear, that F1 must be the guilty party. That code is never exercised when there's a "single click". It is exercised when there's a "double click". I will do a little more sniffing around to see if I can get more details.

Yes, correct, the double click issue happens when using touch. Sorry but I'm working on multiple things right now, so my responses might be slow, but I will definitely follow up and hopefully can nail this one. @GreenSock I'll test with your latest Draggable. Though, that issue does not sound related to mine.

I don't mind the hijacking, but since this edgeResistance thing is a new, different issue, it's better to just start a fresh post so that people can look at it separately. So yeah, good idea to do that. Anyway, I'm not a GS dev, so I am not going to try to look into Julien's issue further (sorry, I got my own troubles! ?). I wanted to see if it might be related to my issue, but since I can't reproduce it locally, I don't think that's it. Julien, I have no doubt this is happening to you, and it does seem like potentially a bug, but it also seems tricky to reproduce. Since you yourself found it did not occur on another device, it will be helpful to get more details about the differences between your two devices for the GS devs. FWIW, I currently believe my own issue is a race condition between the Draggable default onClick handling and my framework's onClick handling. So I'm pursuing the tactic of trying to get Draggable's onClick to handle all the needed clicking in my game. I hope it can be made to work. I will certainly post back here with any results.

I wondered if maybe it was an extension that was messing with his mouse clicks.

I also used Chrome 76.0.3809.100 (Official Build) (64-bit) and did pretty much what you did, no problems. This is very weird. Why does your pointer glow when clicking?

Hey Julien, I browsed to your pen (please verify the link) and I don't see the issue you mentioned with edgeResistance. Please double-check? I'm using a desktop computer with a mouse for testing this. I went straight to the pen and dragged the div off to the right halfway across the page. When it popped back its container, I clicked it, and it responded by showing 1 click, 2 clicks, 3 clicks, etc.

Hey Julien, Thanks for the input! Regarding "click" events, I added a listener for that because it's required for other behaviors in the framework that I'm using for my site, which responds to click events in many, many different places - without any problems up until this "dragging" issue. At least, it hasn't caused any problems that I know about. I think if I go with pointerup, I'm going to have to mess around with the general framework quite a bit, and I fear this will affect other games at the site. However, I'll take a look to see if I can make that work. Just a thing to keep in mind: the source for this site is huge, and my little demo was just an attempt to isolate this specific issue. Reworking the entire site to use the GreenSock framework would be a very time-consuming task, and kind of risky (e.g. what if I couldn't reproduce all the current behavior? I think I could, but there's a risk). I was hoping to do a surgical replacement of the current drag-n-drop solution with GreenSock's Draggable. I get the impression that GreenSock plays nice with other frameworks (at least it does with jQuery, but I'm not using jQuery on my site). Anyway, I haven't given up on GreenSock yet. It may be that I just need to play around with it more. Thanks for the info on edgeResistance. That would definitely be a problem for my site. I'll look to see if I can reproduce it in the case I've been looking at.

Hi, It has taken me a while to get back to testing this issue. As a reminder, my demo has a Draggable applied to a div. The Draggable does not have an onClick method, and it has allowEventDefault:false. The div also has a click EventListener applied to it, separately, and when the div is clicked (or touched), it should increment a counter which is displayed inside it. I was having a problem on an iPad, and the problem went away when I set allowEventDefault:false as suggested above. However, in my post above, I mentioned that I had an old Win touchscreen which was randomly producing double or single clicks for the demo which works everywhere else. I bought a cheap Windows 10 touchscreen device: an "RCA Cambio 10.1" (2-in-1) Windows Tablet & Keyboard" for $99. The only "extra" thing which I did for that device was to install Chrome browser. Because it's brand new, I expect it to behave better than my old Windows touchscreen, which had been dropped a few times. Unfortunately, this new device has the same problem as the old device. I open the demo linked above in Chrome, and click-click-click. Eventually, I get a double count. That is, instead of clicking once, it seems like my "touch" click results in two clicks happening. For example, I just saw this happen: 1-2-4-5-6-7-8-9-10-11-12-14-15-16-17-19... so it's not constantly happening, but it's frequent enough to be reproducible pretty easily. Is there something else I can try to make this work? At this point, I am afraid to go with GreenSock for my drag-n-drop solution because I worry that users with Win touchscreen devices are going to report problems.

That's ... bizarre! I added the viewport meta tag to my demo page, and that did fix the issue for the demo page on the iPad (even with allowEventDefault set to true). My site's index.html page does have a meta viewport tag, though. So, for my card game at least (far more complicated than the demo I created), the "double click" thing is definitely coming from Draggable. When I remove the Draggable code, my other click events fire appropriately. When the Draggable is added, the click event fires twice on the iPad, which causes things to break. But then it got fixed, specifically on the iPad, when I set allowEventDefault to false. So I'm still scratching my head on this one. I will report back once I get the new Win touchscreen device, some time next week, to let people know the behavior on that device.

Dipscom, Just so it's clear, I didn't expect anyone to help with anything other than GreenSock issues. If/when I find an issue, I would only bring it to the forum's attention if I could isolate it outside of my application. Already I'm really happy with the support I've gotten using the forum.

As mentioned previously, I was having trouble with my Windows 10 touchscreen device, a Nextbook. On this device, Chrome sometimes fires two clicks, but sometimes only one. I think this is because the Nextbook is pretty old and dodgy, and runs slow. I notice in Draggable there's some code that says "recentlyClicked = (time - clickTime < 40)". It looks to me like if two clicks occur with less than 40 ms between them, GreenSock is going to count this as "recentlyClicked", and call preventDefault on the event. But for my dodgy old Nextbook, it can happen that there's more than 40 ms between these two clicks. BTW the two clicks appear to be coming from GreenSock. If I remove all the draggable code, I never see two clicks. This kinda confused by this. Haven't read all the responses yet, so maybe something is there. It could be that I'm reading the code wrong or that something else is going on. The problem definitely goes away on a brand new iPad when I set allowEventDefault to false, so at least that problem is solved. And the "2-click" issue definitely goes away when I remove Draggable code. I'm going to bite the bullet, and buy a newer Windows tablet for testing to see if my problems go away there. Unfortunately, some users may have ancient devices which could cause this type of problem for them, too...

Given the results from the second experiment that I did, it seems to me this is a GreenSock issue, which apparently is fixed by setting allowEventDefault to false. Maybe?? I'm going to go down the rathole of trying to replace my own onClick functionality with Draggable's onClick to see if I can fix the issue in Win touchscreen+Chrome too. I have only one card game (Gin Rummy) at World of Card Games which requires cards to be dragged, so I'm hopeful I can confine all changes to that one game.

So I set allowEventDefault:false in this demo. That is the only difference between this demo and the previous one; allowEventDefault is set to false. (By the way, I don't see documentation saying what the default value is for that variable. Am I missing something or is the documentation missing?) Anyway, doing that does indeed seem to fix the issues on almost every browser + device that I tried. Unfortunately, there's still one case where this breaks. I have a Windows 10 touchscreen device called a Nextbook. When I run the demo on the most recent version of Chrome, 75.0.3770.142 (32-bit), the clicks either occur once or twice, randomly. I don't see any pattern to whether there's one click or two happening. I don't know whether it is worth it for your to investigate this particular problem. I did take a look at the Draggable source, and I can see that it must have been quite a nightmare getting it working on many different systems. I'm going to investigate whether the Draggable.onDrag function can be used for my purposes as well. Thank you. I am now a supporter at the "ShockinglyGreen" level ?