Middleware factories currently get run each time a source is set. Because middleware are assocated with a player, the factories should only run once per player.
This PR fixes it so that we associate a middleware instance with a middleware factory per player.
Each time a player is disposed, we will clear the cache of the middleware instances for that player.
Fixes#4677.
Use ResizeObserver when available for better and more performant resizing information, otherwise, fall back to a throttled resize event on an iframe that's the size of the player.
Allows a video.js user to disable this by setting resizeManager: false as an option since the component will not be initialized.
Add a debounce util.
This reverts #4800 (e0ed0b5) because we end up getting two playerresize events with the dimension methods now.
This will allow middleware to interact with calls to play() from the tech. This will require a method of indicating to middleware previously run that a middleware down the chain has terminated or stopped execution.
* Adds middleware mediator method that runs middleware from the player to the tech and a second time back up to the player. This category was created because play is both a setter(changes the playback state) and a getter(gets a native play promise if available). This also has the ability to tell whether a middleware has terminated before reaching the tech.
* Adds a middleware.TERMINATOR sentinel value that is available on the videojs object
* Adds play to the allowedMediators
* Adds paused to the allowedGetters
* Adds a sandbox example of a play mediator middleware
Chrome has started pausing autoplaying video elements when they are
moved in the DOM. Here we need to make sure that if the video started
autoplaying, after we move the element in the DOM we call play again.
Fixes#4720.
The core goal here is to make sure the following works in light of some middleware process that makes setting the source more async than next tick:
```js
player.src('...');
player.ready(() => player.play());
```
In fact, given this change, we should even be able to do:
```js
player.src('...');
player.play();
```
Unlike #4665, which would have clarified/changed the meaning of "ready", it remains a reflection of the tech's state and we make better use of the ability to queue things on that state and on the middleware `setSource` process.
A we retained a lot of references to DOM elements in various components. Here we clear it up. Also, make sure that we remove unused listeners as they can retain objects as well.
Update evented mixin to null out the eventBusEl_ after the component is disposed.
Add a feature for components, to tell it not to auto-initialize the evented mixin.
Re-enable the tests that were removed in #4640.
Add the ability to initialize Video.js with an element named video-js. This is because sometimes, seeing the native element is undesirable, plus, it's cool to have our own element.
Can be used just like the video embed.
IE9 is supported but only with dynamic sources as the source element can only be used inside of the video element.
We added a feature so that remote text tracks can auto-removed when a source changes. However, in 6.x we changed the source behavior to be asynchronous meaning that some text tracks were accidentally being removed when they weren't supposed to be.
For example:
```js
var player = videojs('my-player');
player.src({src: 'video.mp4', type: 'video/mp4'});
// set second arg to false so that they get auto-removed on source change
player.addRemoteTextTrack({kind: 'captions', src: 'text.vtt', srclang: 'en'}, false);
```
Now when the player loads, this captions track is actually missing because it was removed.
Instead of adding auto-removal tracks immediately to the list, wait until we've selected a source before adding them in.
Fixes#4403 and #4315.
Video.js players can accept a number of standard <video> element options (autoplay, muted, loop, etc), but not currently playsinline, which is now part of the [HTML spec](https://html.spec.whatwg.org/multipage/embedded-content.html#attr-video-playsinline). We should add it to the list of <video> attributes that can be provided to the player as options.
Prevent ClickableComponents re-adding event listeners each time enabled() is called.
* Keeps track of enabled state (this.enabled_)
* enable() doesn't do anything if the component is enabled, so the event handlers are not re-added
Fixes#4312
This adds a beforepluginsetup event as well as beforepluginsetup:$name and pluginsetup:$name events.
The drive behind this is improving the ability for people to make cross-plugin dependencies in a more robust manner.
Android Chrome now supports playbackRate properly, so removes the blacklist added in #3246 for newer Chrome versions.
Adds `browser.CHROME_VERSION` as a necessary evil.
No longer blacklists for Chrome 58+ -- this could possibly be fixed since 52, but 58 is all I've been able to test on and most users should keep Chrome up to date.
In the new middleware work, the way that new sources were loaded was refactored. We also recently made techs and components work either TitleCased or camelcased. There was one comparison that didn't do the proper check and cause the tech to be reloaded, even if the two techs were the same.
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.
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.
