iOS 4.2.1 bug?

[Ryan Witt]

Hey, I mentioned this on Steve's blog post, but it looks like the menu
example is broken on iOS 4.2.1. Seeing as delaying js parse and
execution is really important on mobile, it would be good to have this
one work. :)

I took the opportunity to grab a network capture and look at the
waterfall:

Menu withOUT ControlJS: https://uncap.it/shared/fc97ae997f3c844a0cdef20fd8bf9c2d59407c98/
Menu with ControlJS: https://uncap.it/shared/9aaa41090522564ee51a7cddb9d5017b01a2fbdc/

The load times are only a few milliseconds apart (329ms withOUT
ControlJS and 322ms with), and it looks like the "interactive" scripts
loaded in both cases, so I suspected it was an error in the JS.

Then I loaded up Firebug Lite and the example started working. I'll
bet the CJS debug prints are erroring out due to the lack of
window.console and causing the rest of the script not to execute?

Ryan

--
Ryan Witt
http://fastsoft.com/
http://whichloadsfaster.com/
http://uncap.it/

[Server Herder]

This was also reported on the Google code site and happens on all
browsers except ie and opera. A patch has been submitted.

http://code.google.com/p/controljs/issues/detail?id=1

[Steve Souders]

Thanks for starting this thread! I'm trying to organize and rundown all
the cross browser bugs.

I check for console.log before using it, so I don't think that's it. My
guess is this is (yet another) race condition. I'll have to investigate.
If you want, I have a "div" version of console.log commented out in
control.js - you could comment that back in and do some debugging. But
I'll look at it in the next day or so.

Thanks.

-Steve

[Steve Souders]

I just did a nice patch (from serverherder!) and tested on my iPhone and
it works.

You might have to clear your cache.

-Steve

[Ryan Witt]

Works for me now. Is there a noticeable delay after clicking the dropdown on your iPhone, Steve?

[Steve Souders]

Yes - there's supposed to be.

The idea with this example is what to do if you have 500K of JS that
takes a long time to parse & execute, but isn't needed to load the page
and in fact may never be used. The answer is to download the script but
delay parse&execution until the user needs the code. To simulate the
long time to parse&execute I put a 2 second execution delay in the code.
The code is executed when you click on the button so that's when the 2
second delay occurs. I think that's better than forcing a 2 second delay
that blocks page loading (esp. since the code may never be used). But I
completely agree with the blog post comments that a busy indicator would
be appropriate here.

Thanks for testing!

-Steve

[Ryan Witt]

Got it. This is a technology example, not a product design. I'm really surprised how long jquery takes to parse on iOS devices.