Currently, the behavior of time tooltips is inconsistent across iOS and Android devices so we want to hide the tooltips on mobile devices for the time being.
The issue is that in Flash, Flash.embed wraps the object element in a div but that object element is what is referenced by this.el(), so, parentNode isn't null but we aren't actually in the DOM. Instead, just check to see whether the tech element is in the DOM or not via node.contains().
This fixes a logging in the console regarding timetooltips which don't exist. Also, makes sure not to focus the menu button when the captions settings menu item is clicked since the caption settings is getting focused instead. In addition, it makes sure the legend text in the track settings is the foreground color.
In addition, the track buttons need to update on the ready event because when the tech loads, it could run with support native captions, so, it needs to know whether to include the captions settings menu.
And all tracks should always be included in player.textTracks() and not just player.remoteTextTracks().
Implement a `hideThreshold` property that defaults to 1 so
descendants can override it if necessary. Right now the only
descendant that will override will be `CaptionsButton` because
video.js adds a "captions settings" for emulated text tracks.
Move the CC icon in the SubsCapsMenuItem into an icon-placeholder span. Also, include that information for the screen reader.
In addition, only apply default sizing to icon-placeholder if they're direct descendants of a vjs-control.
In #4034, we changed the way that menu buttons work slightly by introduction a wrapper element with a separate wrapper css builder. However, this broke, at least the playback-rate menu.
This PR adds a buildWrapperCSSClass to each of our menu buttons.
Previously timeupdate would fire before the video was playing, and the tech was not ready. This caused issues when preload was set to auto, because cuechange would fire before the video was even started for cues with a startTime of 0.
Wait for tech to be ready before watching for timeupdate
update unit tests to use TechFaker
Add a unit test to verify that we wait for Tech to be ready.
Increase timeout because IE8 can take more than 5 minutes to run.
Increase browser disconnect timeout so that browsers that succeed but don't report back to karma don't fail the build.
Make webpack more quiet.
Dispose players created in hooks tests which also increase stability.
Update videojs-vtt.js and don't auto-export its versions of VTTCue globally.
When our TextTrack object is given a cue, if it's a native cue, wrap it in our emulated vttjs.VTTCue.
Fixes#4093.
It allows you to use string as an key for the language files but have a default value that's different. In this case, we have a key of progress bar timing: currentTime={1} duration={2} which is used so that we have a descriptive key to what is happening. The default value matches that default value in en.json: {1} of {2}. The reason for the default value is so that the translation uses {1} of {2} for the actual localization without requiring en.json to be included in videojs by default.
Fix#4024.
This fixes a lot of the issues from #2746 by making the dialog inherit from our actual ModalDialog which now has tab focus trapping.
The Captions Settings dialog has some accessibility issues:
- Field labels and fields are not explicitly associated
- Keyboard focus does not move into the dialog when it is opened
- Keyboard focus is not trapped inside the dialog while it is open
- Keyboard focus does not return to the control which opened the dialog when it is closed
- The extent (top and bottom) of the dialog is not indicated to screen readers
- The dialog cannot be closed with the Esc key
- The meaning of '---' in the select fields is not clear
- The control to close the dialog is labeled "Done" rather than "Close"
- The purpose of the "Defaults" button may not be obvious, and its effect may not be apparent to screen reader users
- Focus highlighting (outline) on the Default and Done buttons is *very* hard to see
- Pressing the Done button doesn’t seem to have the same effect as pressing the Close (x) button; does it trigger the same focus movement
- This requirement to move it back to the triggering element is tricky, since clicking on that item in the CC menu dismisses the CC menu. I need to think about this a little more - either the menu should open again, or the focus should go to the main CC Menu Button
- The focus outline on the whole dialog goes too far to the left (all the way to the edge of the video window, not just to the edge of the dialog)
Fixes#2746.
Currently, the ARIA value of VolumeBar tracks the value of volume. It should instead track the position of the slider on VolumeBar, which tracks volume except when the player is muted, in which case it's 0.
Fixes#4064.
