Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
killroy

Draggable onRelease fires pre-maturely

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I have following code:

new Draggable($hand, {
 	cursor: 'auto',
 	onPress: function(e) {
  		t0 = Date.now();
  		console.log('handHover.onPress');
 	},
 	onRelease: function(e) {
  		console.log('handHover.onRelease');
  		console.log(Date.now() - t0);
 	}
});

And onRelease fires between 680 and 690 ms after onPress fires. No matter what I do on the screen.

 

It seems some internal mechanism cancels the touch even after around 700ms. How can I disable this and correctly capture touch events?

Link to comment
Share on other sites

Hi,

 

I see no evidence of this behavior in this example: http://codepen.io/GreenSock/full/IgzKa/that largely uses your code.

 

 
Draggable.create(".blue", {
    cursor: 'auto',
  onPress: function(e) {
   t0 = Date.now();
   console.log('handHover.onPress');
    TweenLite.set(this.target, {rotation:45})
  },
  onRelease: function(e) {
   console.log('handHover.onRelease');
   console.log(Date.now() - t0);
    TweenLite.set(this.target, {rotation:0})
  }
})

I tested on desktop with mouse and iPhone 4s with touch.

 

Both the console logs and rotation are as expected. I do not see onRelease firing prematurely.

Perhaps I'm misunderstanding the problem.

 

Please provide more details or a full example that clearly shows the problem.

 

Thanks

  • Like 1
Link to comment
Share on other sites

  • 6 months later...

Wow, just encountered this again and Googling the issue I only find myself with the same question asked and still unanswered.

 

I'm currently tracing into the issue. The release originates from this code in Draggable.js (line 1597):

 
_addListener(_doc, "contextmenu", function(e) {
var p;
for (p in _lookup) {
if (_lookup[p].isPressed) {
_lookup[p].endDrag();
}
}
});
 
It appears that on windows, this code does not get executed, but somehow on android Chrome it does.
 
Any ideas?
Link to comment
Share on other sites

Can you confirm the issue with latest version of Draggable?

<script src="http://cdnjs.cloudflare.com/ajax/libs/gsap/1.16.1/utils/Draggable.min.js"></script>

If so, please provide a demo that clearly illustrates the issue. Feel free to fork the one I provided back in October.

 

And by "windows" do you mean Windows Phone?

 

Thanks!

Link to comment
Share on other sites

Hi,

 

But windows I mean Chrome on Windows (not ...Phone, just "Windows"... the OS). I am working on an HTML5 game and I am developing it on Windows and am currently testing it on Android.

 

This code keeps it working for now:

document.addEventListener('contextmenu', function(e) {
e.stopImmediatePropagation();
}, true);
 
since it disables the rogue GSAP code by pre-empting the contextmenu handler.
 
It seems pretty obvious to me that you cannot cancel a drag operation on a "long press" event, since long presses are what usually start a drag operation.
 
I will try the latest Dragable version when I have time.
 
Why did you link to the CSSPlugin?
Link to comment
Share on other sites

The current version 0.13.0 (I was using 0.11.0) still has the offending code at line 1865:
 

_addListener(_doc, "contextmenu", function(e) {
 var p;
 for (p in _lookup) {
  if (_lookup[p].isPressed) {
   _lookup[p].endDrag();
  }
 }
});

... just confirmed that the same issue persists. Just add some logging there and you'll see that handler firing within a couple of 100ms of pressing the drag-able item.

Link to comment
Share on other sites

thanks for the update.

sorry bout the bad link, fixed now.

Link to comment
Share on other sites

If I understand correctly, it seems like you may just need to add some CSS to your element(s):

-webkit-touch-callout: none 

I'm not sure it's wise to force that kind of behavior inside Draggable itself because some people may WANT to allow the long-press context menu. The code you referenced in Draggable wasn't a mistake - it specifically addresses cases when the context menu is shown (and thus should stop the dragging). See what I mean? I totally understand why in your use case it'd seem odd to permit that, and you'd expect that Draggable would force the browser to ignore long-presses, but if we do that it could seem unintuitive for some other users in their [different] use cases. Perhaps I'm misunderstanding though. 

  • Like 2
Link to comment
Share on other sites

Hey, thanks for your replay (and patience).

 

I agree that default behavior should be adhered to be default. I just am not sure how dragging will ever really work, unless it's a quick swipe action, if after 600ms or so it gets automatically cancelled. Might warrant a mention in the docs.

 

I will try that CSS and report back tomorrow.

 

Thanks.

 

PS: Do you guys show case larger projects using GSAP somewhere? I'm preparing for GDC Europe right now so should have demo-able material pretty soon.

  • Like 1
Link to comment
Share on other sites

Your previously stated solution still works fine, right? 

document.addEventListener('contextmenu', function(e) {
    e.stopImmediatePropagation();
}, true);

Were you advocating for us removing the functionality that cancels the drag when the contextmenu is shown? I'm just trying to follow through and make sure I understand if this should be considered resolved or if you're looking for something else at this point. 

 

Oh, and you asked about showcasing larger projects - absolutely. We'd love to see what you're building. Please pass a link along when you're ready!

Link to comment
Share on other sites

Well, at the very least document this behavior, since by default your code actively interrupts my code.

 

Perhaps console.log a statement: "Canceling drag action due to context menu invocation".

 

The problem is, the code above kills ALL contextmenu events. This works for me as I don't care about these, but ideally I could disable just the GSAP interception of the event and not interfere with other code.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×