Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Wait for chapters track to be loaded #4228

Merged
merged 2 commits into from May 16, 2022

Conversation

joeyparrish
Copy link
Member

addChaptersTrack() was already an async method, but it did not wait
for the chapter data to be loaded by the browser. The solution is to
wait for the load event on the <track> element we create.

To accomplish this, some cleanup and refactoring was done in how
tracks are managed. Summary of changes:

  • The addtrack event, which triggered management of tracks in src=
    playback, is now used for all types of playback. In src= mode, it
    manages all tracks, and in MSE mode, it only manages chapters
    tracks (which are added to the video element as in src= mode).
  • processChaptersTrack_() has been renamed to
    activateChaptersTrack_(), since its only job is to set the
    track's mode field to make the browser load it.
  • activateChaptersTrack_() is now only ever called via the
    addtrack event.
  • activateChaptersTrack_() no longer loops over all chapter tracks
    on a timer, and instead only touches the single track it was
    called for.
  • addSrcTrackElement_() now returns the HTML <track> element it
    creates.
  • addChaptersTrack() now awaits a load or error event to
    complete (or fail) the operation.
  • Existing tests for addChaptersTrack had long delays to work around
    this issue; these delays have simply been removed.

Fixes #4186

@joeyparrish joeyparrish added the type: bug Something isn't working correctly label May 16, 2022
addChaptersTrack() was already an async method, but it did not wait
for the chapter data to be loaded by the browser.  The solution is to
wait for the `load` event on the `<track>` element we create.

To accomplish this, some cleanup and refactoring was done in how
tracks are managed.  Summary of changes:

 - The `addtrack` event, which triggered management of tracks in src=
   playback, is now used for all types of playback.  In src= mode, it
   manages all tracks, and in MSE mode, it only manages chapters
   tracks (which are added to the video element as in src= mode).
 - `processChaptersTrack_()` has been renamed to
   `activateChaptersTrack_()`, since its only job is to set the
   track's mode field to make the browser load it.
 - `activateChaptersTrack_()` is now only ever called via the
   `addtrack` event.
 - `activateChaptersTrack_()` no longer loops over all chapter tracks
   on a timer, and instead only touches the single track it was
   called for.
 - `addSrcTrackElement_()` now returns the HTML `<track>` element it
   creates.
 - `addChaptersTrack()` now awaits a `load` or `error` event to
   complete (or fail) the operation.
 - Existing tests for addChaptersTrack had long delays to work around
   this issue; these delays have simply been removed.

Fixes shaka-project#4186
// If we have moved on to another piece of content while waiting for
// the above event, we should not process tracks here.
if (unloaded) {
return;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean that, if we unload and load an asset with text tracks over and over again, it will leave orphaned event listeners? Since we don't unlisten to any events on the video, on unload.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooh, good question. I see now that in unload() or detach(), we do a lot of unlisten() calls for various events.

This pattern was already in place around track events for src=. If this is the only issue with the PR, how about we let the fix stand as is, and I'll follow-up immediately with a full audit of listen()/unlisten() in Player?

Probably this pattern was never actually necessary, but whoever added it wasn't aware of the way we were cleaning up other event listeners in the load graph. I mean, even I wasn't aware, clearly.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine, yeah.

@joeyparrish joeyparrish merged commit 80e81f1 into shaka-project:main May 16, 2022
@joeyparrish joeyparrish deleted the wait-for-chapter-load branch May 16, 2022 23:10
joeyparrish added a commit that referenced this pull request May 17, 2022
addChaptersTrack() was already an async method, but it did not wait
for the chapter data to be loaded by the browser.  The solution is to
wait for the `load` event on the `<track>` element we create.

To accomplish this, some cleanup and refactoring was done in how
tracks are managed.  Summary of changes:

 - The `addtrack` event, which triggered management of tracks in src=
   playback, is now used for all types of playback.  In src= mode, it
   manages all tracks, and in MSE mode, it only manages chapters
   tracks (which are added to the video element as in src= mode).
 - `processChaptersTrack_()` has been renamed to
   `activateChaptersTrack_()`, since its only job is to set the
   track's mode field to make the browser load it.
 - `activateChaptersTrack_()` is now only ever called via the
   `addtrack` event.
 - `activateChaptersTrack_()` no longer loops over all chapter tracks
   on a timer, and instead only touches the single track it was
   called for.
 - `addSrcTrackElement_()` now returns the HTML `<track>` element it
   creates.
 - `addChaptersTrack()` now awaits a `load` or `error` event to
   complete (or fail) the operation.
 - Existing tests for addChaptersTrack had long delays to work around
   this issue; these delays have simply been removed.

Fixes #4186
joeyparrish added a commit that referenced this pull request May 17, 2022
addChaptersTrack() was already an async method, but it did not wait
for the chapter data to be loaded by the browser.  The solution is to
wait for the `load` event on the `<track>` element we create.

To accomplish this, some cleanup and refactoring was done in how
tracks are managed.  Summary of changes:

 - The `addtrack` event, which triggered management of tracks in src=
   playback, is now used for all types of playback.  In src= mode, it
   manages all tracks, and in MSE mode, it only manages chapters
   tracks (which are added to the video element as in src= mode).
 - `processChaptersTrack_()` has been renamed to
   `activateChaptersTrack_()`, since its only job is to set the
   track's mode field to make the browser load it.
 - `activateChaptersTrack_()` is now only ever called via the
   `addtrack` event.
 - `activateChaptersTrack_()` no longer loops over all chapter tracks
   on a timer, and instead only touches the single track it was
   called for.
 - `addSrcTrackElement_()` now returns the HTML `<track>` element it
   creates.
 - `addChaptersTrack()` now awaits a `load` or `error` event to
   complete (or fail) the operation.
 - Existing tests for addChaptersTrack had long delays to work around
   this issue; these delays have simply been removed.

Fixes #4186
joeyparrish added a commit that referenced this pull request May 17, 2022
addChaptersTrack() was already an async method, but it did not wait
for the chapter data to be loaded by the browser.  The solution is to
wait for the `load` event on the `<track>` element we create.

To accomplish this, some cleanup and refactoring was done in how
tracks are managed.  Summary of changes:

 - The `addtrack` event, which triggered management of tracks in src=
   playback, is now used for all types of playback.  In src= mode, it
   manages all tracks, and in MSE mode, it only manages chapters
   tracks (which are added to the video element as in src= mode).
 - `processChaptersTrack_()` has been renamed to
   `activateChaptersTrack_()`, since its only job is to set the
   track's mode field to make the browser load it.
 - `activateChaptersTrack_()` is now only ever called via the
   `addtrack` event.
 - `activateChaptersTrack_()` no longer loops over all chapter tracks
   on a timer, and instead only touches the single track it was
   called for.
 - `addSrcTrackElement_()` now returns the HTML `<track>` element it
   creates.
 - `addChaptersTrack()` now awaits a `load` or `error` event to
   complete (or fail) the operation.
 - Existing tests for addChaptersTrack had long delays to work around
   this issue; these delays have simply been removed.

Fixes #4186
nyanmisaka added a commit to nyanmisaka/shaka-player that referenced this pull request Oct 6, 2022
@github-actions github-actions bot added the status: archived Archived and locked; will not be updated label Jul 25, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 25, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

Successfully merging this pull request may close these issues.

addChaptersTrack() promise resolves before the chapters file has been downloaded and parsed by the browser
2 participants