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.
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
Overhaul of the tap system so the keyboard does not cover up focused
inputs, correctly bring up the keyboard on text input focus, disabling
focus during scroll, disabling clicks after a hold then scroll,
removing 300ms delay without additional event handlers on each element,
etc. Refactored the tap/click/scroll/activator events for more
testability, along with adding more tests.
Previously I disabled the activation class immediately on a touchmove,
where as the click will still work if you touchstart and touchend
within a few pixels of each other. So visually it may have looked like
the click shouldn't have worked. I just updated it so the use the same
numbers. For example, if you hold down an item and move just 5 pixels,
the item will stay active (before it wouldn't have), and the click will
fire. But at the same time, if you hold down an item, and move a larger
distance, once it realizes that it went farther than 6 pixels it'll not
allow a click to happen, AND it'll not show the item as being active.
Using the :active pseudo works fine for desktop, but mobile is a
completely different beast, especially with the quirks of each
platform. By intentionally not using any :active selectors and manually
adding/removing a .active class, it gives us a precise control on how
the active state works for ALL platforms. Additionally, this places
less selectors in the css, and reduces the possibility of unnecessary
repaints. Currently this method of using .active instead of :active is
being applied to .button and .item elements.
