Add failsafe to get duration during timeupdate
#20
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We noticed that sometimes, unpredictably, the 25-50-75 percentile events would not fire. We could not figure out a reliable way to reproduce the error, but if you add a breakpoint around line 55 here:
videojs-event-tracking/src/tracking/percentile.js
Lines 47 to 71 in 204dba2
...and repeatedly refresh the page while trying to play a video.js player with these events bound, eventually, you may run into a situation where
duration
is equal to 0.It seems that either the
durationchange
event never fired, or it fired before the watcher got bound. In either case, for whatever reason, thedurationchange
callback here:videojs-event-tracking/src/tracking/percentile.js
Lines 83 to 93 in 204dba2
...never ran in those bugged-out instances, so the
first
,second
, andthird
variables never got set.(I'm guessing this could be a browser bug? We are using Chrome 92 on macOS.)
This pull request aims to fix that issue by adding an additional check for
duration
during thetimeupdate
event.I confirmed that this fix works by adding a breakpoint on the
getDuration()
call insidetimeupdate
. By doing the same refresh-page-and-hit-play, I was able to confirm that the code at the breakpoint does occasionally get called (i.e. when it would have broken before), and the percentile events do fire as expected.