dispose() method removes the video element from HTML

[smohadjer]

I can't find any method in the API docs that would allow me to reset changes done by video.js so that DOM would be exactly as it was before video.js is initialized. Usually destroy() method of plugins does so, but all I could find here was a dispose() method which seems to remove the video element from the markup as well. The video element was not inserted by video.js and should remain accessible (via browser's native HTML5 video player) after video.js player is destroyed.

[tegola]

I second this.

[heff]

Can you explain the use case around this more? What scenarios would this be valuable in?

[smohadjer]

My use case is a play list where clicking links in play list should update the main video, both source and the poster image. Since poster can not be updated via API method .poster() (due to bug that has been fixed, but not released yet), I decided to destroy the videojs instance, update the src and poster attributes in markup, and then initialize the video.js. I don't want to remove the video element with all classes and data-attributes that sits on it, as then I have to rewrite the whole markup via js every time a play list link is clicked.

[heff]

Since poster can not be updated via API method .poster() (due to bug that has been fixed, but not released yet)

Version 4.4.0 went out yesterday. Would you mind trying that out and seeing if poster() works for you now?

[gkatsev]

Have you tried using one of the playlist plugins. Might help out with creating the playlist, specifically.
Though, a reset or something method that resets vjs and the video element back to pre-init state might still be useful.

[heff]

That would make sense. The hard part is that in some cases we trash the original element and reconstruct a new one. Like on iPhone where it doesn't like you moving the video element in the dom. The new element is for use in the tech only, and wouldn't have all the original attributes.

[smohadjer]

Can't you store a clone of the original element before making changes to the DOM and use it in dispose() method to restore things back to initial state? That's what I ended up doing to resolve my issue.

[gkatsev]

Theoretically possible. Would you be willing to create an exploratory PR which provides this functionality via a new API method?

[ange007]

I support creation of a similar functionality.
Also I can help with testing if necessary.

[heff]

I'd still be interested to know if now that the poster() fix is out, if this is still an issue. But otherwise I think the combination of the poster fix and #1050 should address the use case here.

I'm going to close this for now, but if there are other specific use cases for restoring the original html tag I'd be interested to hear them, so please post them here.

[kdmny]

I have a use case that might support this feature.... I have a carousel of "things" (could be a video, could be another carousel of images, could be text) implemented using a 3 div pattern: previous frame, current frame and next frame. The user can see and interact with only the current frame at any given time. The entire carousel of "things" to be viewed may total in the hundreds. As the user swipes through the carousel, previous, current and next are updated to reflect the user's position in a larger storyboard.

Imagine a scenario when the 3 divs all contain video tags. Only the current div's video tag needs to be a videojs object. The other 2 are waiting to be turned into videojs objects. The user is free to transition between the 3 divs in either direction. Each time they transition, I create a videojs object to manage playback. When they go next or previous, I'd like to destroy the videojs object to save memory.

Suppose the user is watching the current frame's video and decides to navigate forward. In this case, I'd like to call dispose(), but when the user navigates back I can't reconstruct the videojs object because the video tag is no longer in the DOM.

I'm injecting a clone of the video tag after destroying as a workaround, but it would be simpler if videojs offered an option to leave the DOM intact.

[ange007]

I have also similar type of use.
Function very much would facilitate life.

[tamlyn]

Another use case into the mix: the responsive site I'm working on uses VideoJS at larger screen sizes but the native player at smaller sizes. The site is designed to bind/unbind behaviours as the breakpoint is crossed (which happens when an iPad is rotated, for instance). Ideally I would init VJS when switching to large layout and uninit it when switching to small.

I know I can work around this but it means making an exception to the way all other components on the site are designed and it feels messy.

[mmcc]

@tamlyn rather than init / dispose the player when switching back and forth, would it be easier to turn on / off native controls?

[marifehe]

@gkatsev @mmcc I have similar scenario than described here, where I use videojs as a fallback, but would like to restore the original video element in some cases. It is this still a functionality wanted? If so, I could make a PR that would store the original html element when videojs is initialized, and restore it with a new method in the API, like restore or reset.
Will that be useful or is it something similar already?

[RobertLowe]

Re-open? This would be nice when switching from say a video (hls) to a MediaStream smoothly, I noticed videojs does a lot of requestAnimationFrame needlessly when using URL.createObjectURL(stream) or attaching a stream via srcObject. Seems the player hasn't moved forward to work with WebRTC nicely?