-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detection for buggy raf implementation #2
Conversation
…have been called in window scope instead of created AnimationFrame object scope
Conflicts: AnimationFrame.js AnimationFrame.min.js
Conflicts: AnimationFrame.min.js
with static userAgent sniffing due to further bugs in animationFrame implementation on iOS 6+7
Hmm I have done this to avoid agent sniffing ... lets see how we can solve this using feature test. We can assume that there are other devices out of there we don't even know which have the same problem. |
do you have a ready example for this issue? |
Well, I hope this plunk will demonstrate the problem. I couldn't test it right now, I don't have an iOS device at hand right now. I'll test it tomorrow. The point in the plunk is that the draggabilly lib is using RAF (it will use it if it's available and shim it if not, it has no workarounds for iOS bugs). When the draggable element hovers over one of the red boxes, it will cause a transition (2s should be enough to demonstrate the problem) which will prevent the draggable element's position to be updated on iOS 6+7 until transition is over. |
Tested on iphone 5 v.6.1.4 safari - works well, chrome - dragging works very bad without to hover over the red boxes. |
The script doesn't limit the update frequency, I didn't optimize it at all. I'll compare it tomorrow with the implementation that we are using in our project to figure out what's missing to trigger the bug. |
Ok thanks! |
any news on this? |
Well, I finally managed to trigger the bug on iOS6 (iPhone5) with my plunk. Triggering it on iOS7 (tested on iPhone4) was a breeze but Safari on iOS6 is much more robust. Nevertheless, here is the plunk I prepared for you. You will have to drag the draggable pretty fast to see the glitches. It is not that RAF is called only after the animation is finished as I described before but from time to time its execution is delayed while other elements are still animating. To be honest, it is far easier to reproduce in our project, but it's not released yet and I can't refer to it to demostrate the bug. In our project, the draggable's position really isn't updated as long as you drag it and other elements are animated, but as soon as you stop dragging, its position is updated immediately. |
Thanks, I can reproduce it too. Lets see what can be done. |
Any ideas for feature detection on this? |
couldn't find time ... will try asap |
I think we can't fix this well. The situation you have is where you mix 2 different ways to move objects which seem to block each other. Not using native raf on this devices per default is not an option, since the situation you have is a special case. I think you want to move your boxes using transformations. |
It might be just worth a documentation notice with your example to prove it. |
It's really hard to say and even harder to detect. Maybe, you should provide an explicit config option for people who want to detect buggy platforms by sniffing UA strings by thremselves, they could then hard enable the RAF shim instead of the native implementation. |
Yeah, thought about this too. I will add this option. |
Another proof against part of the community decision to rely ONLY on feature detection, wiping out platform detection (as jQuery removing its $.browser). We need both, and more important, we need to let the library user choose. |
This doesn't proves anything. Its a very specific case, engine detection is required for a very specific conflict. jQuerys move is correct, people are relying on sniffing where feature detection is possible. Browser sniffing is a very bad thing and should be used ONLY if NO other way is there. Also they have created an official plugin with the old engine sniffing code. They just try to make clear the right way to code. |
Nevertheless, my last sentence was perfectly clear: "We need both, and more important, we need to let the library user choose." As library designers, we need to be open minded and putting barriers and force users to think some particular way is dangerous. CSS is a perfect example of awkward design with things like "table are only for tabular content" and stuff. 10 years after it's still horrible to deal with certain layouts in CSS3! We could talk about multiple inheritance and stuff. But I think you got it. Please never consider something as bad as forbidding people to use it, it's a despotic choice. |
it was there, seems like it has been removed https://github.com/jquery/jquery-browser Nobody is forbidding this, its just making it clear unrecommended and now also officially unsupported. |
please check out the latest version |
Currently, the script performs feature detection by executing raf once and if it returns assuming that implementation is not buggy.
However, there are currently 2 issues with raf on iOS 6 + 7 (tested with both):
We have currently exactly this behaviour, we try to transition some elements while we are dragging another one. The drag is done via raf and element position change handler is not called as long as transition takes place. Tested with iPad2/iOS6.1.3, iPhone5/iOS 6.1.4 and iPhone4/iOS7.0.
This commit removes the feature detection and introduces a userAgent string check to match iOS6+7 powered browsers.