Firefox 65 update on Browserstack is causing issues with our builds. We should pin to firefox 64 until we have time to investigate.
Also, add a commented out snippet to enable video recording on browserstack for when we see issues.
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)
