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 :(