CCCEV HDC CheckIn

That sort of thing (devices auto-updating themselves) has always been problematic and is not best practice for mission critical environments. We've disabled auto-updates on our Win kiosk devices for the same reason/fear. We definitely recommend people NOT upgrade their iPad kiosks (mission critical production devices) unless they know they're functional.

We'll try to take a look at this sometime this week right now.

We don't auto-update either, but the fact that if we need to buy a new iPad for check-in (which we may need to for one of our campuses) and it will come with iOS 5 pre-loaded...

In looking at the NoClickDelay 'class' in ios.js, I'm wondering if returning false might help. I've always gotten mixed results from e.preventDefault(). It seems to behave inconsistently in nearly every browser, however, returning false from the end of any given event handler seems to behave more reliably.

Just to catch myself up, what problem was the NoClickDelay object solving? Sorry, my memory is a little fuzzy on those details. :)

// EDIT - K... Comments are definitely helpful. Is that .5 sec click delay still a big problem with mobile safari?

// EDIT 2 - The problem seems to be related to focusing on the search textbox. We're digging into it...

yes, it is still a problem. I tried removing the noclickdelay code completely and it was unbearably slow again.

I don't think it is the actual noclickdelay code that is the problem, I think it is something that changed in iOS 5 that has become prevalent in the WAY the noclickdelay code runs. I commented out all the actual code so all it did was create a "no op" touchstart handler and I had the same problem.

I am wondering if it is an issue along the lines of:

iOS 4 would only issue a single touchstart event at a time, the way the code was written this would be fine. Perhaps now in iOS 5 Safari Mobile now issues multiple touchstart events for a single "touch" which is causing issues because the stored variables are being wiped out and causing things to go awry.

The problem is every time a textbox field gets focus the virtual keyboard pops up. Among other things we're looking into, we're trying to determine if there is a way to disable the popup keyboard.

I've never found a way to stop the keyboard from coming up in the mobile browser. If we had our own application we could prevent it, but the only stuff I have ever seen online says to mark the field as read-only... which doesn't really accomplish what we want.

A side effect of the "noclickdelay" code was that it prevented the phone number text box from getting the focus, so it solved two problems at once. But we may need to modify the core.js code to not give the phone number field the keyboard focus if a mobile device is detected.

I will also be looking into fixing the noclickdelay code this week. Everything went fine this past weekend so I can start dealing with new problems now.

Daniel Hazelbaker wrote:

I've never found a way to stop the keyboard from coming up in the mobile browser.

Yeah, I'm having a hard time finding anything that would indicate we can prevent it -- that's disappointing. :(

Should you reassign this to Jason? Jason and I are about to sit down (XP) and refactor that whole section of the js code -- something that is long overdue. The intent is we can then manage that part of the code easier than we can now. Wish us luck.

Yeah, I think you're right Daniel. We're looking at rewriting that section of code that manipulates the phone number entry. Basically, we're looking at suppressing any focus event on that textbox by immediately blurring and rewriting that part of the core JS to be less bad. :)

Feel free to re-assign it to one of us if you'd like. We're pairing up on it and I've got my personal iPad running iOS5 to test against. Any changes we make, we'll submit into ReviewBoard.

Ok, new plans. Here's what Jason and I just discussed:

1. We're going take Ryan's patch, examine it, and implement that for 1.4.0.
2. Jason (and I) are not interested in doing "maintenance" on checkin-core.js in its current state. So Jason is starting a major refactor of the entire checkin-core.js for the 1.5.0 release. We've learned so much about proper JS in the past 6 months and will incorporate many best practices. (I'm saying 1.5.0 because there are going to be so many changes that I think it warrants it.)

Comments/Concerns?

Since this only affects iOS 5.0 I would say one of two things:

1) we release 1.4.0 without this fix and have a "hot fix" download of an updated ios.js file with that patch (so all they have to do is overwrite the original ios.js file) for those running iOS 5.
2) we release 1.4.0 WITH this fix and have a (so to speak) "hot fix" download with the original ios.js file so that people still running iOS 4 can restore the original functionality if they need to.

Since it is a one line fix, either way we do it it should be pretty easy to have a download from either a forum topic or wiki page or whatever with instructions on where to put the file and what it does.

Daniel Hazelbaker wrote:

Since this only affects iOS 5.0 I would say one of two things:
...

I like option 1. As long as there are no further objections, we'll do that. Now, since I rolled out 1.4.0 to our production environment, my only objection is that it (loading the "search" screen) seems very slow. I'm looking into that now.

OK, so talking with Ryan, he claims to have seen good results by simply removing line 4 of ios.js:

document.addEventListener("touchmove", function(e){ e.preventDefault(); }, false);

I'm not sure that's necessarily the root of the problem, but I do have a feeling that e.preventDefault() alone is not stopping the event from bubbling up. I'm wondering if returning false from that callback might behave more consistently. As I've been refactoring our JS codebase, I've rolled the ios.js code into checkin-core.js. In the next week or two I'll do some more extensive testing see if my theory holds water.

So for the "hotfix" patch we'll release for 1.4, we can just release a modified ios.js file with that line commented out. And for 1.5, we'll release the refactored code that I've been working on the last few days.

Agreed, it seems to make the problem less.. well.. problematic; but it definitely is not the root issue. the e.preventDefault() does indeed stop the "touchmove" event from moving up the chain as that I can verify instantly (and did). It seems like just putting an addEventListener() on a "touch..." event is what is causing all the problems - which makes no sense.