By default the scroll bar is being created for each view, then
immediately it adds the .scroll-bar-fade-out class. On every transition
you sometimes saw the scroll bar appear then fade away quickly. Sure
that was annoying and has been fixed to prevent that, but the real
issue is that on every view transition, the scroll bar’s opacity
transition fired off a transitionend event, which bubbled up to the
view and messed with Angular’s $animate. If timed out correctly, at the
time the scroll bar’s transitionend event bubbled up, and an element
was actively leaving the view, it would confuse $animate and cause the
leave animation to abruptly end, which caused an ugly flicker.
Previously if this script was executed after the window was loaded, none of the callbacks would fire.
See https://developer.mozilla.org/en-US/docs/Web/API/document.readyState for definition of detecting the `load` event.
TODO: Potentially this is redundent, since maybe using `ionic.DomUtil.ready` would mean one less listener. However I don't know if the listeners attached to `ionic.Platform.ready` require the `document.readyState` to be `complete` rather than only `interactive`.
Linked to #2229
It was possible that when switching between tabs, and creating a
navigation history in one of the tabs, then switching tabs again, it
could clear out the individual tab stacks under certain scenarios.
Closes#1978
When an actionsheet/popup is open, everything under it has
`pointer-events:none`. However, once they are removed then the click
prevent was removed immediately too, but the click that comes in 300ms
later was still firing whatever would have been underneath the
actionsheet/popup. Instead, wait 400ms before removing the click
prevent, which would block the native click. Closes#2204
When a state change happens, ensure the keyboard is hidden. When a
keyboard is hidden, ensure all pending timers our cleared. When
resetting scrollView, ensure it’s only doing it when it has to.
For testing: #1670#2192
If the containing ionTabs directive is being destroyed, then child
ionTab directives should not don't bother going through its
controller’s `remove` method, which selects a new active tab as each
ionTab is being destroyed. By selecting a new active tab as each tab is
removed, it causes unnecessary view loads, transitions and multiple
`viewState.changeHistory` events.
I added a bit of detail to ready function to remind folks that - in the context of a web browser - even though ready has fired it is *NOT* going to allow for device specific features. It may be too obvious, but I really think a reminder here will help.
