In commit 31a305d, we moved this repo to the `@silvermine` org and
updated the `name` field in package.json. The Gruntfile uses the name of
the package as the name of the JS output file. Therefore, when the
package name field changed, so did the JS file output name and path. We
no longer depend on the name field in package.json for the name of the
JS output file.
- All the dev dependencies were updates in package.json.
- prepublish was replaced by prepare to fix "warn prepublish-on-install As of npm@5, `prepublish` scripts are deprecated" & "warn prepublish-on-install Use `prepare` for build steps and `prepublishOnly` for upload-only."
- node-sass was added in package.json and a require('node-sass') was added to Gruntfile.js since the new version of grunt-sass requires it (see: https://github.com/sindresorhus/grunt-sass/releases/tag/v3.0.0)
Since VideoJS 7, once the player has started, any subsequent calls to the update() function on MenuOption will prevent the playback menu from fading out. The workaround I found was to remove the call to update() when a new quality is selected. The selection behavior was already handled by the MenuOption handleClick function so I just had to remove the previously selected option.
When the HTML5 preload attribute is set to 'none' or when using Safari (even when the
preload attribute is not 'none'), the video does not resume playing after the quality is
changed using the quality selector menu. The quality selector plugin was listening for the
'loadeddata' event in order to know when to resume playback, but the 'loadeddata' event
does not fire when the preload attribute is set to 'none', and Safari does not fetch
enough data to emit a 'loadeddata' event.
Previously, the SourceInterceptor made the assumption that the QualitySelector button component
is a direct child of the controlBar component. That may not always be true. Video.js allows you
to specify a nested hierarchy of components, and so when plugin users choose to move the
QualitySelector button elsewhere, the plugin does not work properly.
This commit introduces a new event type called QUALITY_REQUESTED to signal when the user is
requesting a quality change. The old QUALITY_SELECTED event is now used to denote when the
plugin actually uses a new quality source. This dichotomy eliminates the need for the
SourceInterceptor to have a reference to the QualitySelector button component.
From a basic functionality standpoint, this accomplishes the same purpose as
the previous implementation using `_.omit`. However, rather than removing the
`selected` attribute from the sources, this will keep the structure the same by
only altering the value of the source.
If your usage of this plugin requires a stable source format, e.g. for
comparing sources to see if the source changed, please provide the `selected`
attribute when programmatically setting the player source. At this time, we
don't have a simple way to standardize the `selected` attribute on initial
source load. (i.e. It's up to the programmer to set the initial format on the
sources before giving them to the player)
As things turn out, the middleware constructor is called every time `setSource`
is called [1]. This was causing a new listener to get bound to
`QUALITY_SELECTED` on each change by the quality selector. :( This change makes
it so the listener is only bound on the initial creation of the player.
[1] 03529163b6/src/js/tech/middleware.js (L66)
