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.