jQuery Shim: Potential queueing issues on iOS6.x.x

[scalvert]

Hey Julian,

I'm encountering a particularly nasty issue in iOS6. We're using filament group's fast tap implementation to remove the 300ms tap delay on devices. On iOS6, I seem to be able to get my code into a state where the inprogress sentinel is not set.

Putting a console.log statement around line 2785 shows that the value of $.queue(element)[0] !== "inprogress" is false. This means that the animations don't get fired, and my code breaks (no subsequent taps/clicks work).

Any thoughts on what could be causing this? We're using zepto + shim, so perhaps it's the shim's $.queue implementation?

It works on iOS7 with Zepto. If I swap to using jQuery (no shim) it works perfectly every single time on iOS6.

Swapping it back to Zepto + shim and following the exact same steps, I can get it to break every single time. I narrowed it down to that line of code where the queue is simply not returning the inprogress sentinel.

The steps to reproduce are:

1. git clone https://github.com/mobify/bellows.git
2. git checkout bellows-2.0
3. grunt serve
4. Open mobile safari on iOS6 and go to http://localhost:3000/examples/default.html
5. Perform the following actions, in this order
   • click to close the first header
   • click to open the second header
   • click to open the first header
   • click to close the first header
   • click to attempt to open the second header (breaks - no animation fires)

You need to perform the steps above fast enough for it to break, but once you do it once it's simple to reproduce.

Sorry I couldn't give you a more stripped down example. Let me know if you need me to try anything else.

[kpeatt]

@scalvert Is it worth mentioning that this isn't (as easily) reproducible if you're either instrumenting using Safari or running simulator and that an actual device is needed? Seems like there's a bit of a quantum bug going on here in that it stops being broken when you measure it.

It is weird but it does seem to be the case. We can reproduce 100% of the time on actual device when not instrumenting — that number drops to near 0% when we're running instrumentation. Our methods now involve us doing some judicious logging to page instead of attempting to check through Safari. Again, not sure if you're still in town but we'd be happy to give you access to our devices to try it out.

[scalvert]

I had traced it down to the sentinel that's used in the animation queue, so that's the best place to look. I'm feeling like this is a timing thing, as hooking up the Safari inspector to instrument an iOS device appears to add some latency.

[kpeatt]

@julianshapiro To your question of what changed between 6 and 7 — and to make this a further head scratcher — it works fine in iOS5.

We tested on 6.0 and 6.1.3. Broken on both. Works everywhere else.

[julianshapiro]

I ordered a real iPhone running 6.x.x.

And... I give up. Makes no sense. I've copied jQuery 1-for-1 at this point. The shim's code is jQuery's extracted code.

---

About 4.36% of active iOS users are running iOS6 as of this month. I'm going to have to just put a notice about a lack of iOS6 compatibility and hopefully most people don't mind.... :-/

I should mention that iOS6 usage dropped by an absolute 1.2% in the last 30 days: https://mixpanel.com/trends/#report/ios_7. If we assume a constant rate (in reality, abandonment is probably accelerating), almost no active iOS devices will be running iOS6 in less than 4 months.

Of course, I say almost because there are still devices that never switched from iOS5. About 2.25% of total devices. I presume these are corporate/educational/retail devices that no one has updated.

[julianshapiro]

@scalvert: Do you get the bug here: http://julian.com/research/bellows_5/examples/default.html. I turned debug on so that Velocity outputs to the console, and this seems to have fixed the bug from occurring as often.

[scalvert]

Yep. I get it by following these steps:

1. Load page
2. Tap first bellows item (item closes)
3. Tap second bellows item (item opens)
4. Tap first bellows item (item opens)
5. Tap first bellows item (item closes)
6. Tap second bellows item (ITEM DOESN'T CLOSE)

Step 6 is the point of breakage. I can reproduce this about 90% of the time using a fairly regular cadence of tapping.

The plan is to move to Velocity being a library that is entirely external lib free right? If so, perhaps focussing on that instead with an eye to providing a jquery plugin for those who want it would be a better use of time.

[julianshapiro]

This is the way it becomes external lib free. There's no other way to do it :(

[julianshapiro]

Help

If you're coming from Twitter and are interesting in helping, here's where you can grab the current version of the unreleased shim: http://julian.com/research/velocity/build/velocity.jquery-shim.js

Just load that before Velocity (instead of loading jQuery). Then, you'll be animating via Velocity(element(s), propertiesMap, options) instead of $elements.velocity(propertiesMap, options).

For queueing behavior, utilize the before and complete callbacks instead of jQuery's $.queue(), which you obviously no longer have access to. (See Velocity's documentation for more info if needed.)

The crazy part is you're going to need an iOS device running 6.x.x or be willing to downgrade your iOS7 device to iOS6, which I hear is difficult to do (but I have not tried it myself). As per the conversation above, the bug will not appear if you're using a simulator.

Ask any questions you have here. I'm always available to answer.

Or maybe someone has an idea of what type of bug notoriously disappears on iOS6 when instrumenting? At least that might be able to point us in the right direction.

[julianshapiro]

Current Status

@scalvert For the sake of anyone trying to help, I'm trying to create a reduced test case. Unfortunately, I can't seem to trigger the bug. Could you pretty please help me modify this so that it breaks on iOS6?

http://jsfiddle.net/julianshapiro/rL04zzsw/12/

My unit tests have been passing recently, so now I'm wondering if the problem rests with your implementation. You said you once switched to jQuery and that it worked, but switching to jQuery also means not using Zepto. You also have tons of custom code wrapped around these Velocity calls. Too many potential conflicts abound.

If we can't reduce my fiddle to a test case that produces the bug, I might actually conclude that it's not my shim and release it as-is.

[julianshapiro]

I'm releasing the shimmed version publicly now. If you can strip down the triggering bug issue within Velocity, I will look into this further.

[scalvert]

Sounds good. It may not be easy to repro in a stripped down test case, which I understand makes it difficult to fix if it's difficult to repro.

Sorry for taking so long with this. I've been working on performance testing so we can potentially move away from using Zepto entirely.

[julianshapiro]

Np :)

Sent from my phone

On Aug 21, 2014, at 12:36 PM, Steve Calvert [email protected] wrote:

Sounds good. It may not be easy to repro in a stripped down test case, which I understand makes it difficult to fix if it's difficult to repro.

Sorry for taking so long with this. I've been working on performance testing so we can potentially move away from using Zepto entirely.

—
Reply to this email directly or view it on GitHub.

[julianshapiro]

I'll close this for now. If you reduce the case, I will seriously address it. If anyone else reports similar issues, I will look back into this.