holgersindbaek

For this reason, also, I'd suggest reworking the documentation for Draggable to make it more clear that pointerX and pointerY are preferable, whereas event.pageX and pageY are to be avoided unless you really know what you're doing (which I did not).

Woohoo! Draggable's pointerX and pointerY do the trick. I added a query string to the existing demo page to demonstrate this new implementation, which uses this.pointerX and this.pointerY. @GreenSock I'd suggest adding the information that you gave above about pageX and pageY to the onDrag documentation. I don't know if this is spelled out anywhere, but the docs led me to believe that pointerX and pointerY were identical to event.pageX/pageY. It didn't occur to me that using those would give different results from what I was doing. @ZachSaucier Thanks much for verifying! You reminded me that I should test on Firefox. I installed, and the new implementation also works fine with Firefox.

Additional info: I tested this on my RCA Cambio Win 10 using three different browsers: Chrome, Internet Explorer, and Edge. Event.pageX and pageY are undefined only in one of these, Chrome Version 76.0.3809.100 (Official Build) (32-bit). Edit: I tested this on an iPad, and the issue does not show up in Safari or Chrome. It seems to be isolated to Chrome + Win touchscreen devices. Can anyone verify?

I have a new Draggable issue. I need to retrieve event.pageX and event.pageY in the Draggable.onDrag method. This works fine, and as expected, on my desktop, using a mouse. It is broken in my RCA Cambio Win 10 touchscreen device (Chrome), when using touch to drag the Draggable (it works if I use the device's mousepad). The issue is that event.pageX and pageY are both undefined. I have a demo page at my site. Draggable.onDrag docs indicate that event.pageX and pageY should be accessible and defined when dragging: onDrag: Function - a function that should be called every time the mouse (or touch) moves during the drag. Inside that function, "this" refers to the Draggable instance (unless you specifically set the scope using onDragScope), making it easy to access the target element (this.target) or the boundary coordinates (this.maxX, this.minX, this.maxY, and this.minY). By default, the pointerEvent(last mouse or touch event related to the Draggable) will be passed as the only parameter to the callback so that you can, for example, access its pageX or pageY or target or currentTarget, etc. So far, I'm having a lot of success switching over to use the Draggable.onClick method instead of the click handlers in my site's framework as mentioned in my previous post. Fixing this issue could be the last thing that I need to make it work. Advice? Am I missing something, or is this a bug?

Yes. The problem is that my "demo" example works fine with your new code, but using Draggable in my game still doesn't work reliably - sometimes it looks like 1 click is fired and other times it's 2. Rather than trying to chase down this new problem, I'm now trying to get rid of my click handling and replace it with Draggable's. If I run into the 2-click issue again, I'll post here. If I run into some different issue (which is starting to look possible), I'll start a new thread. Thanks for being so responsive; it is appreciated!

@GreenSock It appears that your beta version fixes the issue with my demo. Unfortunately, there's a lingering issue happening at my site. I understand all the issues with different browsers, and you have my sympathy. It's really annoying that there isn't some standard for this behavior. Since you recommend using Draggable.onClick so strongly, I'm going to go back to trying to rework my code to use that. If I can get that to work, it's probably more "future-proof" as well. It doesn't look like it will be easy, but it seems like it should be possible to do that.

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 ?

Thanks for the welcome, jonathan! I am trying to avoid using GreenSock for anything other than dragging functionality. There's already a framework in place for handling clicks/presses; I don't want to have to rewrite any of that code. If I can just use GreenSock for dragging, then it's super helpful. I plan to subscribe if I can get that working.

The reason I'm trying to avoid using Draggable's onClick is because I'm just trying to grab the "drag" functionality, and add it to a huge code base which uses another library entirely. The existing code base has a different framework for dealing with clicks. I suspect that trying to make GreenSock handle clicks will cause bugs in other ways. Just trying to disturb the existing code base in the most minimal way, hope that's clear.

Thanks for the quick response! I've got a bunch of different devices and browsers to test on... I'll report back asap.

I've recently been trying to integrate GreenSock into my website in order to take advantage of the Draggable element. I was able to get it almost working, but I found what looks like a bug on the iPad. I am not sure if the issue is due to touchscreen, per se, or something specific to the iPad. I have a working piece of code which demonstrates the issue, here. To reproduce the behavior: 1) Visit the above link, and click the square with the blue outline. It is a Draggable. However, just click it, don't bother dragging it, since the issue occurs with a simple click. Notice that when you click it, the counter increments by 1. That is correct behavior, because I have a click handler on that square in addition to the Draggable. 2) Now, visit that link from an iPad, and touch the square with the blue outline. Same code, different behavior: the counter increments first by 1, then there's a slight flash, and then it increments by 2! This indicates a click event was fired twice. This is a problem for me. Why is click happening twice? Is there some way to stop it? I need the same behavior on both mouse clicks and touch clicks. You can read the source code if you want to see what's being done. But basically, I create a Draggable on that blue square. I have a completely separate event handler for the click event (I'm not using Draggable's onClick property, and would very much prefer not to do so). Can anyone help with this? Is it a known issue, is it... a feature? Is there some way I can handle this without doing contortions to detect iPad/touchscreen? I will create a Codepen URL if anyone wants me to do so, but the code is just there in my link.