pm33

Just tested on iPad Air running latest iOS and Safari and was easily able to reproduce the same bug. UPDATE 1: I have not been able to reproduce the bug on the Draggable example on (http://greensock.com/draggable) on the same devices. I can get it to drop the drag element without triggering any events but it doesn't break all draggable elements (as in you can just press and drag it again). UPDATE 2: I am using e.stopImmediatePropagation() in my onPress and onDragEnd functions. When I remove this it functions exactly the same as the Draggable example on (http://greensock.com/draggable) as in it only drops the draggable element without triggering any events and can just be selected and dragged again. Both e.stopPropagation() and e.stopImmediatePropagation() produce the same behavior. Any ideas on how to trigger some event in this situation and also stop the propagation (The page has swipe handlers from Hammerjs that I don't want triggered while dragging). UPDATE 3: Using monitorEvents(document) in Chrome DevTools there doesn't seem to be anything unusual and all the correct events are being reported. Like you said earlier it does seem to occur when pinch zooming the element. When using stopPropagation it is possible to get draggables working again by pinch zooming a draggable element (it does not have to be the same element that caused the issue nor is this consistent by any means. Hope this make sense).

Thanks Jack. I don't have the device on me now so I can check exact versions but for me it was happening on a Nexus 7 running Android Lollipop, current Chrome version off Google Play store as of 8/05/15 and also inside a Crosswalk project (crosswalk-project.org) running the Canary release version 14.43.341.0. I am also using Hammer.js 2.0.4 in the project and that's the only other thing I can think of that may be messing with things. EDIT: Device: Nexus 7 running Android 5.1.0 Chrome version: 42.0.2311.111

Any updates on this? I am experiencing the same issue.

Yep perfect, thanks for the explanation.

With TweenLite.set(...{force3D:true}) will setting the opposite, TweenLite.set(...{force3D:false}) remove it from a composite layer straight away, on next tween or not at all? I need that sort of control otherwise GPU Memory will be an issue. I will try adjusting the lagSmoothing. Would the process be something like: * set TweenMax.lagSmoothing(300, 33); * init and start animation Timeline and then set it back to default on onStart, onComplete or would somewhere else be better suited? EDIT: Using TweenMax.lagSmoothing(40,17); seems to be working quite well. Are these settings too low to leave on the whole time? Any major drawbacks?

Hey, I am currently working on a project that requires full page transitions. As an example pages are div elements that are approximately 1024x600 in size and contain content. Pages slide in and out from left to right (emulating the ebook feel). At the moment the page change/transition process goes like this: * Page in view has visibility 'visible' and willChange '' set * set willChange 'transform' on outgoing page *Slide outgoing page out of view * set visibility 'hidden' and willChange '' on outgoing element after animation finished * set visibility 'visible' and willChange 'transform' on incoming element. *Inserted delay (~300ms) - to allow some breathing room for browser paint times and composition(layer creation) *Slide incoming page into view * set willChange '' on incoming page once animation is finished I have put in the delay to give the browser time to paint and promote the div to a composite layer before animating for smooth animations. However the delay required on different devices obviously varies. Is this something lagSmoothing can help with or does any one have any other/better techniques for this type of situation? Jack has already suggested: Don’t alter the will-change property at all. Take the layerization hit at a time that’s less critical. Maybe at startup (not sure how many things you may have to layerize, so you may have to stagger things). You can, for example do TweenLite.set(element, {force3D:true}) and it’ll get layerized right away. That way, when you actually go to animate its transforms, it’s already layerized and ready-to-go. My understanding was that setting will-change:'transform' on the element layerized when it is set, so is there any differences between using that or TweenLite.set(element, {force3D:true}) ? The other thing is deciding when to layerize the pages. Because the pages are quite large doing all the pages ahead of time floods the GPU memory and would probably kill the device so it seems the only option is too layerize pages as they are needed. Since that can take some time depending on the device I am currently inserting the delay during the animation sequence to help but I would much rather a more dynamic approach (no need delaying on devices that dont need too or might need longer). Any input or advice would be appreciated, thanks.