A pull request (#1430) was merged that added a requestAnimationFrame polyfill to
the window on platforms that do not have rAF. This was overlooked.
This now has created conflicts with Angular 1.2.17 on Android browsers
that do not have requestAnimationFrame.
The problem was that a polyfill for requestAnimationFrame was put onto the
window for Android <4.3. AngularJS would then check if
window.requestAnimationFrame existed. Angular's check passed, and then
it would try to use cancelAnimationFrame which was undefined.
Now, nothing on the window is changed.
Gesture hold event and ionic’s tap will both fire since the tap has no
strict duration between its start and end (a click will always fire no
matter how long the press is held). If a hold event fires from
ionic.Gesture, then the simulated click which would fire on
touchend/mouseup should be canceled.
With the previous implementation, Chrome complains:
"'webkitCancelAnimationFrame' is vendor-specific. Please use the standard 'cancelAnimationFrame' instead."
This fixes that by reusing (copy-paste) the code from angular.js
A better way would be to use ionic.requestAnimationFrame and ionic.cancelAnimationFrame everywhere, but that is more involved and risky...
To allow select elements to change options in Firefox, the simulated
tap click should not go through when the target is an `option` element.
However, the regex was too general and also prevented
`ion-option-button` on mouseup.
Addresses #1373.
Before: if an `<a>`, `ng-click`, or `<button>` inside of a .item,
was clicked, the activator would walk up .item and activate it.
Now: If an `<a>`, `ng-click`, or `<button>` inside of a
.item is clicked, the activator will activate that element.
Additionally, CSS was added so `a.item-content.activated` would look
activated.
Some browsers already remove the delay with certain settings, such as
the CSS property `touch-events: none` or with specific meta tag
viewport values. However, each of these browsers still handle clicks
differently, such as when to fire off or cancel the event (like
scrolling when the target is a button, or holding a button down). For
browsers that already remove the 300ms delay, consider Ionic's tap
system as a way to normalize how clicks are handled across the various
devices so there's an expected response no matter what the device,
platform or version. Additionally, Ionic will prevent ghostclicks which
even browsers that remove the delay still experience.
If a text input is located in the same area as a button which was just
tapped, which was probably because of a view transition, the text input
gets focus 300ms later. This is an issue on Android because it also
fires off a mousedown event. Resolved by remembering the touchend
target then checking if it’s different from the mousedown target.
Closes#1370
