…e responder chain, it is unnecessary to provide extra code paths
… ensure input value is not written unncessarily
…crollView on iPad. The comment says it all.
…rollView that I'm determined to fix, but until then if we're going to throw an exception about it, we should at least spell correctly.
…tracting the absolute start position from the relative current position. This meant that the ScrollView would always grab any dragging touches, even if they haven't actually passed the tolerance amount. This is particularly bad when you have nested ScrollViews, the inner ScrollView would never get a chance to scroll.
… the location of the browser without triggering the actual routing. Makes the use of 'statecharts' and 'routing ' much easier.
…a empty function for sparseArrayDidRequestIndexOf in the default case. This always falls back to looking locally
…targets are always on top
…otherwise it alters the styles of nested scroll views that were rendered earlier. Plus made the chained binding observe one less object, since parentView should never change for a scroller.
…after the following bug fixes) than in the default version)
…ause of where Handlebars hooks into view rendering process
… the first time, rather than updating
…ve yet fired and that touchEnd() will come in in the same Run Loop as the one that started with the call to touchStart(). The bad thing that happens is that even though we cleared this.touch, occasionally if touchEnd() comes in right at the end of the Run Loop and then the timer expires and starts a new Run Loop to call beginTouchesInContent(), that this.touch will STILL exist here. There's no explanation for it, and it's not 100% reproducible, but there is about a 40ms window where the firing timer and the end touch cause a crash. What happens is that if we try to capture the touch that has already ended, assignTouch() in RootResponder will check touch.hasEnded and throw an exception.
…leaving a comma behind
… against the root responder