Ensure that the YouTube <iframe /> is really in the DOM before calling

[iantanwx]

This just ensures that the iFrame is mounted in the DOM before calling this.player.stopVideo(), or else an uncaught error results. I encountered this in the course of embedding this component in a draft-js based editor with cut and paste operations, causing the iFrame to be removed from the DOM before componentWillUnmount was called.

[cookpete]

I'm not sure why this is necessary. What is the harm in still calling stopVideo even if the iframe is somehow removed from the DOM before componentWillUnmount is called?

[iantanwx]

This causes the YouTube SDK to throw an error that stops the parent component from working entirely. The SDK appears to keep a reference to the node, and when that node is taken out of the document before any attempts to control the player are taken, the SDK will complain.

…

On Tue, 25 Apr 2017 at 3:52 AM, Pete Cook ***@***.***> wrote: I'm not sure why this is necessary. What is the harm in still calling stopVideo even if the iframe is somehow removed from the DOM before componentWillUnmount is called? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#180 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKGtDFFzC2ehzRXepS7Dn28b1KnF-ebCks5rzP1ygaJpZM4M5wVB> .

[iantanwx]

E.g. React-player component is mounted. React-player DOM node is removed from the DOM by some non-react action. State is updated causing componentWillUnmount to fire. Player node is no longer in the DOM. SDK throws errror.

…

On Tue, 25 Apr 2017 at 4:40 AM, Ian Tan ***@***.***> wrote: This causes the YouTube SDK to throw an error that stops the parent component from working entirely. The SDK appears to keep a reference to the node, and when that node is taken out of the document before any attempts to control the player are taken, the SDK will complain. On Tue, 25 Apr 2017 at 3:52 AM, Pete Cook ***@***.***> wrote: > I'm not sure why this is necessary. What is the harm in still calling > stopVideo even if the iframe is somehow removed from the DOM before > componentWillUnmount is called? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#180 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AKGtDFFzC2ehzRXepS7Dn28b1KnF-ebCks5rzP1ygaJpZM4M5wVB> > . >

[cookpete]

Ah yeah I see the error now. Checking the iframe is in the DOM can be simplified to

document.body.contains(this.player.getIframe())

However, a fatal error occurs on every player method without this check (not just stop()) so I think a bit of refactoring is needed to apply this check to every method call.

The real solution is: do not let a non-react action remove the player from the DOM 😉

[iantanwx]

Thanks, the problem is that draft-js has to allow the native cut event to occur. Otherwise the system clipboard will not be populated with the correct data. This causes the iframe to be removed from the DOM before state updates, which is why this check was necessary. There is no good way to fix this without a long and protracted PR to the draft-js repo, being as it is used in production by Facebook. Thanks for the help, I noticed you committed another change that I believe fixes the issue.