Jump to content
Search Community

Draggable onRelease fires in mobile device after a moment

Sahil test
Moderator Tag

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

Hi,

 

I had created a infinite slider using GSAP which you can drag as well. Just today I noticed that even if I keep holding the slide, the onRelease event fires in draggable on touch devices while on desktop it works fine. I guess that's intentional behavior? How can I change it to stop autoplay if user isn't swiping?

Link to comment
Share on other sites

Not really sure about what you are describing. It would really help if you could create a very simple demo that clearly illustrates the problem with onRelease using as little code as possible.

 

I quick test shows that onRelease will only fire when a release happens:

See the Pen yoPeLL by GreenSock (@GreenSock) on CodePen

 

 

If the issue is present in that demo please let us know what OS and browser you are using. Looks good on this end.

  • Like 3
Link to comment
Share on other sites

I don't think it's getting released, it's not firing the onPress because on certain devices in order to accommodate native touch scrolling, it has to wait for the first movement to discern the user's intent. Your code is written in such a way that it'll keep moving the element unless the onPress is fired, so I bet you're assuming it is calling onRelease because it keeps moving (right?). 

 

Try setting allowNativeTouchScrolling:false on the Draggable. Seemed to work well for me. 

  • Like 3
Link to comment
Share on other sites

No it actually fires onPress event and then fires onRelease, I have updated my pen for color change. allowNativeTouchScrolling:false does the trick for firefox but causes issues with scrolling so I prefer to keep it true.  Opera is behaving same in either settings. Here in video you can see onRelease getting fired in both pens.

Link to comment
Share on other sites

What happens if you set explicitly touch-action: manipulate which prevents the 300ms click delay on mobile, since touch-action: manipulate tells the browser your intent, and then it doesn't have to have that mobile 300ms click delay. That is one reason why Chrome devs added support for  touch-action: manipulate. You might need to use the !important declaration for touch-action: manipulate to override the inline style of touch-action: pan-y currently being added inline.

 

Mozilla added touch-action property support for the new pointer-events spec like 5 days ago. Not sure if that was pushed to Mozilla Firefox Mobile Browser app.

 

Does that help in any way either by adding touch-action: manipulate or even trying touch-action: none to see how it is affected?

 

:)

  • Like 3
Link to comment
Share on other sites

No that didn't help but I guess I will let it be.

 

I think what it causes it is the browser feature to long press and select text etc. So just now I selected some text from random element in opera and tried long pressing on target element and onRelease event isn't firing anymore. Which is not any solution but explains what is happening or at least I guess so. Firefox on the other hand keeps behaving same even if you keep some text selected. Luckily chrome works fine.

 

Edit: found this thread which does help me, I will see if I should use it or not.

Link to comment
Share on other sites

It works fine for me in iOS. I poked around some more and it looks like those browsers on Android make it pretty much impossible to solve because:

  • The long-touch triggers a "touchcancel" event (which in turn causes Draggable to call onRelease, as it should). 
  • That's likely because the long-touch triggers a contextMenu, but of course you don't want that which is why Draggable intercepts that event and calls preventDefault() and stopPropagation() in that case. This should, in theory, prevent that touchcancel from ever occuring...but in the browsers you mentioned on Android, that doesn't seem to be the case. It fires it anyway. 
  • Once the "touchcancel" event is fired, it basically kills the interaction and "touchmove" events aren't fired anymore (until you touch again, of course). That's why Draggable calls the onRelease. It SHOULD. We can't just have Draggable ignore the "touchcancel" because it'd act like the press is stuck. Moving your finger wouldn't drag because the browser is now refusing to fire touchmove events. 
  • The only way to circumvent all this is to call preventDefault() on the original touchstart event, but if you do that, it will refuse to allow any touch-scrolling. This is why setting allowNativeTouchScrolling:false fixed the issue - it allows Draggable to call preventDefault() on that touchstart event. But you said you want to keep native touch-scrolling. On Android devices, Draggable must wait for the first movement to discern the user's intention and either preventDefault() or not on the event. 

So it's quite a conundrum. Due to odd behavior on Android browsers, as far as I can tell it's logically impossible to get all the behavior you're asking for. 

 

It doesn't even work to set touch-callout and user-select to none (which typically would prevent any context menu). No matter what, that touchcancel event  is triggered. Unless I'm missing something. Please let me know if you (or anyone else) can figure out a solution. 

  • Like 2
Link to comment
Share on other sites

Quote

The only way to circumvent all this is to call preventDefault() on the original touchstart event, but if you do that, it will refuse to allow any touch-scrolling.

Ya I was going to ask if it will be good idea to follow thread I mentioned in previous reply, but ya it disables touch scrolling completely. Thanks.

 

Quote

Please let me know if you (or anyone else) can figure out a solution. 

I had given up already  once I found out contextmenu is causing it and after reading your research I think only choice is to let it be.

 

Sorry for assuming you are ignoring my thread. Thanks alot.

  • Like 1
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.
×
×
  • Create New...