Disable the live tracker on IE11 when the document is hidden to fix the slow down and eventual crashing of web pages on IE11.
After #5879 was completed, we noticed that live streams still have an issue. This is because the live tracker we have also uses setInterval. Unfortunately, just disabling setInterval in the live tracker was not enough. Instead, we decided the best course of action is to just disable the live tracker altogether.
1. We were not always able to clean up `resize` on the `ResizeManager`, as the iframe
contentWindow can disappear before dispose
2. Native Tracks on Safari do not have an `off` so we have to deal with
event listeners manually
Fixes#5878
The seek bar updates on a 30ms interval to have a nice, smooth transition as time ticks forward. Unfortunately, IE11 has some performance issues with interval when the document is hidden. This doesn't appear to be an issue when using setTimeout but using a setTimeout was causing the play progress to appear very jerky in comparison.
Instead, we should just not update the play progress when the document is hidden. Besides solving the issue in IE11, it makes sense to do as no one could be seeing the progress bar. In addition, update() is now a no-op if the seek-bar element isn't visible.
Fixes#5575
Issue #5831 made the not-in-DOM warning work with elements from other
documents. This works in modern browsers but IE11 doesn't include a
contains method on the document. Instead, we should check to see if the
body contains the element.
The resetProgressBar_ method was calling 'updateContent' on the durationDisplay and remainingTimeDisplay controls without checking to make sure they exist
Fixes#5838
In Safari, if we call play early and we are going to be waiting till
loadstart, it's possible this will take too long for the user activition
flag to still be available. In this case, we should call load() on the
player to prime the video element so for when loadstart happens.
Extend keyboard support for the SeekBar, and pass unhandled keydown events from components back to the player.
Switch from raw keycodes to the keycode module.
Using `userActions.hotkeys`, which can either be a function to match the hotkeys plugin, or an object with properties like `fullscreenKey`, see the documentation for more info.
This is currently off by default, we will consider turning it on by default in the future, see #5765.
Fixes#4048, fixes#3022.
The ResizeManager's iframe element is able to be focused via tabbing, which results in a bad user experience for users that rely on a screen reader to navigate the video and its sibling elements. The fix is to set the tabIndex to "-1", and the aria-hidden property to true for good measure.
This reverts the previous fix (2bc90a1)
and also simplifies handling. Seems like this works a lot better while
also ensuring that the vjs-fullscreen class is still on the player.
Fixes#5685, fixes#5745
A child component may have been assigned to another
parent before assigning that child component to the
new parent via "addChild" method. In this case, the
original parent should remove the child then it can
be safely added back to the new parent. This commit
will keep the parent's "children_" and its DOM
element's child nodes in the consistent state.
This was done to make the behavior on Android with HLS live streams better but the it's opening us up to too many potential issues, like a user not being able to properly disable the control bar, that we should just back it out.
Before the fullscreen API was un-prefixed, we listened to triggered a
`fullscreenchange` event on the player manually. This worked fine
because a prefixed `fullscreenchange` event was triggered on the player
element itself. But when it was unprefixed, we ended up with two events
now, the unprefixed event and the one we triggered.
Instead, we should listen the event the browser supports and re-trigger
it as the unprefixed event as necessary.
We also make sure that the handler gets calls when the document level
fullscreenchange handler gets called so that it is cancelled properly.
Fixes#5685.
`loadMedia` accepts a MediaObject and an optional ready handler. It'll reset the player -- including text tracks, poster, and source -- before setting the new provided media, which include sources, poster, text tracks.
`getMedia` will return either the provided media object or the currently set values for sources, text tracks, and poster.
Fixes#4342
Listen to 'mouseenter' and 'mouseleave' events when triggered in the control-bar and temporarily sets inactivity timeout to zero before restoring it.
Closes#5258
To make the seek-to-live component more accessible, we hide the text that says "LIVE" from screen readers and make it be purely for sighted users. Then set the control text to be either "Seek to live, currently playing live" or "Seek to live, currently behind live" to indicate what this control does and be informative around whether we are at edge or not. Then use aria-disabled on control if we are at edge.
- Update the Control Text in the load-progress-bar during loading, remove unnecessary Control Text from the play-progress-bar, and hide the time-tooltip feature from Assistive Technology using ARIA.
- Add a span around the vjs-control-text-loaded-percentage in load-progress-bar, and use that for the text to update.
- Hide the time-tooltip feature from Assistive Technology using ARIA
Fixes#5251
The desired behavior when navigating any of the TimeDisplay components (current time, duration, remaining time) with the arrow keys with a screen reader is for the singular parent div to receive focus, and the reader should announce the text of each child span in order, ex. "Current Time 0:17" and "Duration 1:10". This is how it works when using JAWS. However, with VoiceOver each individual child span element receives focus and the contents are announced separately.
According to the ARIA spec (see [here](https://www.w3.org/TR/html-aam-1.0/#details-id-124) and [example 8](https://www.w3.org/TR/wai-aria-1.1/#presentation)), there is no implicit role for span elements, so the contents should be exposed but the elements themselves should be invisible to screen readers. In other words, <span> Sample Content </span> should be the same as <span role="presentation"> Sample Content </span>. But this is not the case with VoiceOver. As far as I can tell, the desired behavior is only achieved with VoiceOver if each child span is explicitly made presentational, either by assigning each of them the presentation role, or by assigning the parent div a role that makes its children presentational (although there doesn't seem to be a role whose semantics fit the purpose of that div)
The first ARIA doc link above shows the Mac OS X Accessibility Protocol mapping for span elements is to the group role. I don't know enough about accessibility API mapping to confidently draw conclusions about root cause, but this seems like a possible explanation.
Changes:
* add role="presentation" to each of the two span elements inside TimeDisplay divs
* add aria-hidden="true to the TimeDivider (tangential improvement)
* fix inaccurate description of the TimeDisplay component (tangential improvement)
- Make sure that we seek to live playback on the first timeupdate
- Do not report that we are not live before playback has started (a timeupdate has been seen)
- Prevent negative seekable increments
- We can seek past the seekable value in the video element, so we use that to seek to live, rather than waiting for a seekable end change.
When liveui is enabled, allow seeking during the live window, add button that allows you to seek to the live edge and that indicates whether you are at the live edge or not.
This is a follow-up to this fix in VHS, after which default in-manifest subtitles were still not being correctly enabled. The reason is because Video.js's text track preselection logic was running before the media groups were set up in VHS.
Text track preselection should happen on `loadedmetadata` instead of `loadstart`. According to the HTML spec, text track data is available on `loadedmetadata`, so we should be waiting until then to make preselection decisions.
