v2.0.0-beta.4

Removes some dependency tree vulnerabilities, and fixes an issue with volume adjustment (#430). Thanks @RobinGiel!

v2.0.0-beta.3

This is a release only for @cassette/player. It fixes the display time in the player UI to round down to the floored time value always (#429). Thanks @abrahamian!

v2.0.0-beta.2

You can now force the player to reload if something goes wrong with the network. (#426).

We also try to recover automatically.

v2.0.0-beta.1

Note that the full 1.5 -> 2.0 beta changelog is here!

Removed

• Remove support for displayText property on track which was supposed to be removed already (27132dd)

Fixed

• Fix bug where initial track duration is always derived from first track (ac4b6ab)

Security

• Update dependencies to resolve security vulnerabilities (0643530)

v2.0.0-beta.0

The full 1.5 -> 2.0 beta changelog is here!

Script and CSS files included below... that's a lot of files! (Maybe we need a better way to organize them..)

v2.0.0-alpha.34

Very minor final breaking change before beta. The PlayerPropTypes export no longer has types exposed for aspectRatio or progressDirection which I highly doubt anyway was using anyway, bust just in case...

v2.0.0-alpha.33

Fixes

• In v2.0.0-alpha.29 we introduced a bug where attempting to adjust the volume would just move the volume to one extreme. This would also have affected any other use of the ProgressBar component where the progress bar moved or resized on the page. This was all due to a mistake in a performance refactor for the progress bar, where we stopped correctly monitoring changes to the progress bar's bounding box. Since the volume bar first renders hidden, it had a 0x0 bounding box, and never updated.

v2.0.0-alpha.32

One of the last pre-beta releases!

Breaking changes

PlayerContextProvider takes a few event callbacks.. onActiveTrackUpdate, onTimeUpdate and onTrackPlaybackFailure. In order to preempt future problems where we want to add more function arguments and the call signatures get unwieldy, we're going to convert these all to single-argument hashes while we're still allowed to make breaking changes.

Before

• onActiveTrackUpdate(track, trackIndex)
• onTimeUpdate(currentTime, track, trackIndex)
• onTrackPlaybackFailure(track, trackIndex, event)

Now

• onActiveTrackUpdate({ track, trackIndex })
• onTimeUpdate({ currentTime, track, trackIndex })
• onTrackPlaybackFailure({ track, trackIndex, event })

New features

One motivation for the change above was wanting to minimize confusion while supporting previousTrack and previousTrackIndex arguments for onActiveTrackUpdate. So now you can have:

onActiveTrackUpdate({ track, trackIndex, previousTrack, previousTrackIndex })

v2.0.0-alpha.30

Features

• The MediaPlayer controls are now completely navigable/controllable by keyboard, the first of several accessibility features tracked in issue #261. (#396)

Improvements

• Better formatting for timestamps (particularly timestamps over 1 hour) (#397)
• More flexible media status bar layout that never wraps the timestamp (#398)

Fixes

• Respect track duration property during initial load (was only respected when tracks are changing before) (#392)
• Don't jump back to currentTime: 0 while loading a track at a timestamp other than 0 (#392)

v2.0.0-alpha.29

Breaking changes

• The filenames for the @cassette/hooks package were being output as cassette-core before - it's now cassette-hooks as intended. If you were using the package with the wrong filename already, that will be a breaking change for you. (#389)
• The ProgressBar prop onAdjustComplete now receives the progress value at the time adjusting completes, which might break something if you were passing the onSeekComplete context value directly (that function expects a timestamp, not a 0-1 progress value) (#386)

Fixes

• Some significant seek performance improvements for the ProgressBar and all components which consume it (MediaProgress, MediaProgressBar, VolumeControl). Previously we performed layout computations up front and updated all consumers of the progress state on the page at once via Context. This made clicking and dragging on the progress bar show noticeable lag. Now we pre-cache the needed style computation and re-render the active progress bar before anything else on the page, better ensuring a responsive interaction. (#386)
• Before we would collect an excess buildup of requestAnimationFrame callbacks while Cassette was running in a background tab - particularly the Cassette docs page. This could cause the page to be totally unresponsive when re-focusing the tab. That issue should now be gone. (#387)