All my sites that use FlexSlider on iOS7 (Chrome and Safari) seem to have issues when you swipe on the '.flexslider' container. When you for example swipe down (on your container), hold it and then move left or right it moves your slide and after that it just seems to lock up.
It seems to be an issue with CSS transitions in iOS7, 'useCSS': false, seems to fix it.
I'm not seeing this on my devices (iPhone 5 & iPad Mini, iOS7). I checked multiple sites where I'm using flexslider (with CSS transitions) ranging from version 1.8 to 2.2
@thomasvankerckvoorde same here, I’m using latest version but with a Picturefill.
if you'll set "useCSS: false" will work
Yes, I know that, but I prefer smooth css transitions. But useCSS: false is a good temporary fix.
I'm also having this issue.
I’m noticing this especially on small screens; in my case, the flexslider element is full-width below about 700px. Attempting to scroll the page on this section causes all gestures to stop working almost immediately (causing scrolling to fail). It seems much harder to cause this to happen with a larger screen (e.g. iPad), though it does happen. No console errors in Chrome. Setting useCSS to false seems to solve this for now.
Seems like flexslider is abandonware.
I have observed this issue as well.
I am also facing this issue.
Seems like this is a real issue with iOS7’s transition implementation and/or a flexslider bug. Something that might speed things up is to post a test case (JSbin, CodePen, etc). I’m snowed under at the moment, but if anyone has some spare time it might help.
"useCSS: false" will not work for me on iOS7 … any other suggestions?
I had the issue initially, but it started working again just a couple days after iOS7 launch. It's possible there was an update to iOS 7 or something that allows you to swipe sideways and then scroll down.
i found that webkitTransitionEnd/transitionend event never fired sometimes which cause this issue.
after i add a flag to control,it fixed.
when transition duration is gone,the flag never changed,and i did a trigger event.
I have experienced the same issue. More specifically I have noticed that the flex slider breaks only once I come to the end of a repeating carousel (e.g. of 4 items when I swipe from 1 to 4 or from 4 to 1) while swiping in both a down/up and left/right (x and y) motion. When I disable the animationLoop option CSS transitions work fine.
I was able to work around the problem by setting useCSS or animationLoop to false.
Although useCSS:false works, it would be great to have this enabled as the transitions are much nicer.
Agreed, I am currently working on/suggest creating a fix similar to what @ilovezhangxue posted above and @maccman wrote about in January: http://blog.alexmaccaw.com/css-transitions (using timeouts to trigger a consistent transition end).
My slider locks up after a vertical scroll (swipe starting in the slider). It no longer advances and does not respond to swipes or tapping prev/next buttons.
I've observed this problem mostly only when orientation is changed to landscape mode from portrait mode. After orientation change, the banner just freezes entirely and no longer responds to any events, causing it to be almost impossible to scroll the page due to the banner taking up most of the page.
What could be the problem, only on iOS7?
We have noticed that useCSS:false to get around the IOS7 issue was causing Flexslider to lock up on some versions of IOS6—specifically 6.0 (10A405). Until a real update, we are currently flipping out the useCSS variable based on if the user agent is IOS7 or greater. Not ideal, but a quick patch for now. We'll keep watching for a fix.
Try setTimeout workaround for iOS 7 freeze issue
See FlexSlider pull request 882 woothemes/FlexSlider#882 and issue 853 woothemes/FlexSlider#853
Implemented a setTimout workaround for consistent webkitTransitionEnd…
… event triggering as described here: woothemes#853
I've the same problem and i can reproduce it on http://flexslider.woothemes.com/
Tested on an iPad2 iOS 7.0.4 Mobile Safari:
Start scrolling the page within the slider. Than at the same time also slide the slider and leave the touchable area.
Keep your finger on the display the whole time!
I've captured it on this video: https://www.youtube.com/watch?v=5K7dnpkZf1Y&feature=youtu.be
It brings the slider to dead on every second try.
Add a setTimeout fallback for the transitionend listener
Webkit doesn't always reliably fire transitionend in some circumstances,
which can cause the slider to stop responding.
to ".flex-viewport" and it will be smooth :)
Any news on this issue? I still able to break slider on iPhone by sliding horizontally and vertically simultaneously. Any workarounds or hacks to patch the issue? useCSS: false didn't work.
Looks like this was fixed in f0e9b4c
@gapple Yup, tested it on prod. Had to adjust "selector" option for the newer slider JS call. Thanks!
unfortunately the bug appears on my iPad Mini Retina (iOS 7.1.2) with Safari and Flexslider v 2.2.2. Everything works fine, until I touch the screen on the slider area (either for swiping or just simple tapping). Then the slider stops advancing automaticall (although it does respond to left-right swipes).
I am still having this issue on Safari with iOS 7.1.1 It seems that when a user scrolls through a website that they use a diagonal type motion which seems to trigger this a lot.
Also experiencing this issue using iOS 7.1.2 (iPhone 4S), has anyone found a fix for this? Here is my site wp.themechills.com/eternity/
I'm also experiencing this on iOS 7.1.2 on my iPhone 5S and the iOS Simulator. Setting useCSS to false fixed it for me though.
Yes, this still seem to be an issue on iOS. Seems to happen if you begin scrolling first, then while scrolling you drag the flexslider as well.
FWIW, I've encountered this issue too. The "webkitTransitionEnd transitionend" event definitely isn't firing, dunno why. Setting useCSS to false fixes the issue as it bypasses CSS transitions and thus doesn't need to listen for those events.
I was having the same issue on iOS8 mobile safari. added what @Semmie suggested and the problem seems to have gone away! Thank you!