Seeking rapidly with the keyboard controls now leverages the existing
logic for handling rapid mouse-based seeking. A new method
(changeTo()) has been added to manage this.
This also moves the keyboard control handling from keyup to keydown
events, to handle holding down the key. Previously, holding down the
key triggered the native key handling of the input element.
When you hold down a key, you get multiple keydown events. When you
release it, you get a single keyup event. So when the user holds down
the left arrow, we weren't actually doing anything. Instead, the
keydown handler built into the input element was handling the event.
By switching to keydown events, we get those multiple events when the
key is held, and we get to handle them the way we want, instead of
letting the input element handle them in a way we can't control.
Finally, since we already had a keydown handler on the window to
manage tab navigation, this renames the two handlers to make it clear
which keydown events they handle (on which target).
Closes#3234
Change-Id: I862159adb238436dac7df6451a0f3e3c3f912360
This fixes the renaming of the protected members of SettingsMenu and
RangeElement, both of which are useful to apps building custom UI
plugins.
In order for those app-level plugins to access the protected members
of the base class, they needed to be part of an external interface.
Otherwise the compiler would rename them.
Closes#2923
Change-Id: I2edb9f1428789fac1e6c60ec6a68b20cdd249ae5
When the controls are hidden, the seek bar should not respond to touch
events. But since the seek bar is a child element of the controls
panel, it receives the touchstart event before the controls do. So
there is no good opportunity to stop the propagation of the event.
I tried using the capturing phase of the event, but that didn't work.
So instead, we let the seek bar know if the controls are shown, and if
not, ignore touch and click events.
Further, I changed the mouseup, touchmove, and touchend event handlers
to ignore the events if the corresponding start event (mousedown or
touchstart) was ignored. That way, you can't accidentally start a
drag operation while the controls are hidden.
Closes#2888
Change-Id: I6ee393e3d631ad3d2a8f7314af692004240fb2bd
This fixes all the license headers in the main library, which corrects
the appearance of the main license in the compiled output.
It seems that the `!` in the header forces the compiler to keep it in
the output. I believe older compiler releases did this purely based
on `@license`.
Issue #2638
Change-Id: I7f0e918caad10c9af689c9d07672b7fe9be7b2f3
The UI seek bar on touch screen devices was broken in PR #2036 and
v2.5.4 - v2.5.11 for live content. VOD content, which starts at 0,
was unaffected.
This fixes the range calculations for touch events to correctly
account for the minimum seek range.
Closes#2558
Change-Id: Ic3f6230d88703fd0ea1c9bc15057c0656b1dc42f
This reflects changes in Google's policy on JavaScript license
headers, which should be smaller to avoid increasing the size of the
binary unnecessarily.
This also updates the company name from "Google, Inc" to "Google LLC".
Change-Id: I3f8b9ed3700b6351f43173d50c94d35c333e82b4
Don't mark the event as passive, so Android can
process it properly.
NOTE: I still see occasional glitches while
seeking a live stream on Android, but the
behavior is much better. There might be another.
smaller bug affecting this, though.
Closes#2169
Change-Id: Icdad0b0029c201a50fd45da34c0361088b9d00d5
Use touch events to sync the range element's value when the bar is touched.
This means you no longer have to touch the tiny ball on the seek bar on iOS.
Fixes#1918
This factors out common functionality and structure from the volume
bar and seek bar, both of which involved specific CSS workarounds for
IE. The seek bar had logic to keep the value from jumping around
during casting, which now the volume bar benefits from, as well.
Finally, the seek bar code was spread out throughout controls.js, and
now it has its own class.
Closes#1913
Change-Id: I299476ccbc27f28f7b225a6e6f8b0d21abe5baf2