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

Target already setup when changing player options #12

Closed
sirajtahra opened this issue May 6, 2019 · 5 comments

Comments

@sirajtahra
Copy link

commented May 6, 2019

###Expected Behaviour
changing options after player initialization should reinitialize the player without a problem.
###Current Behaviour
changing player options outputs: 'Target already setup'

###description
initPlyr method destroys the player then creates it, after the destruction the videoElement getter method returns a video element which still contains the plyr instance, however document.getElementsByTagName('video')[0].plyr returns undefined at this point.

I wonder if this could be a change detection or NgZone issue

@sirajtahra

This comment has been minimized.

Copy link
Author

commented May 6, 2019

the destroyPlayer() method does not seem to update the this.videoElement properly

@smnbbrv

This comment has been minimized.

Copy link
Owner

commented May 6, 2019

Hi,

thanks for raising the issue.

I think the primary issue is that the element that is called original in the original library is not an original element; it's a clone instead.

See https://github.com/sampotts/plyr/blob/80aa6ffe435b170466838f977d52438a95e22186/src/js/plyr.js#L149

I need to think on a stable and reliable solution for that

@sirajtahra

This comment has been minimized.

Copy link
Author

commented May 6, 2019

they clone the original element so it doesn't get lost when you destroy the plyr instance so it seems, I made a pull request that addresses this issue

@smnbbrv smnbbrv closed this in 4f81dfc May 6, 2019

@smnbbrv

This comment has been minimized.

Copy link
Owner

commented May 6, 2019

the problem is it gets lost, because the clone !== element.

Yep, I saw the PR, the problem there is that it uses undocumented / internalelements.original, that's why I can't take it as a long term solution.

However, it helped me a lot localizing the issue, thank you!

@smnbbrv

This comment has been minimized.

Copy link
Owner

commented May 6, 2019

Please check @1.2.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.