Editor: Fix redirect which can occur upon dropping media

[aduth]

This pull request seeks to resolve an issue which can occur when trying to drop media onto the editor after having opened and then closed the media library.

Implementation Notes:

The solution here is to revert <DropZone /> from a React.Component to a React.createClass component. It was originally converted to a component class in #5383 (cc @ockham , @gwwar).

I've spent the better part of my day trying to determine the cause of this issue. I had narrowed it down to that the <DropZone />'s window drop handler was not being triggered (perhaps being unbound) when dropping after the media library had been previously opened. In the TinyMCE media plugin there is dance which occurs when opening or closing the modal to oppositely render the main page <DropZone />. The unbounding theory would seem to imply that the bound functions instantiated in the constructor were shared between rendered components, which I was unable to prove. However, that it works with React.createClass where methods are auto-bound does lead some legitimacy to this theory.

An alternative approach to consider is binding to the window drop events in the <PostEditor />, calling preventDefault. The benefit to this is that it also prevents unintended redirects when accidentally dropping a media file outside the displayed droppable area.

Testing instructions:

Verify that you can drop media into the post editor and media library, regardless of whether the media library had been opened already within the same editor session.

Test live: https://calypso.live/?branch=fix/editor-media-drop-redirect

[timmyc]

I had the issue happen ( dropping media opening media ) to me on Sunday. I can't remember if I had opened the media dialog prior to encountering the bug, but I can not remember the full path I took. Is there any other possible flows that are known to cause the problem that should also be tested?

[aduth]

This was originally referenced via p4k3M4-26N-p2 (cc @ryanboren). There weren't any additional details and I was only able to stumble upon this specific problematic flow through trial and error.

[gwwar]

Seems like this is very easy to repo in prod. Verified that this branch fixes the issue. Let's get this in and investigate what's happening. It seems like we could run into a lot of odd behavior if this is doing something that we don't expect, especially as we port more components to es6 classes.

[gwwar]

Poked around a bit too on master, and I confirmed that that the onDrop even doesn't fire in the editor after opening/closing the media modal.

There's an unmount for the media library dropzone that is fired after the editor dropzone mount, so that does look very suspicious.

[ockham]

Yikes, sorry for causing this issue, and thanks for fixing it.

(FWIW, the reason for converting those createClasses to React.Components was some weirdness with tests when changing those __autoBindMap attributes to prototype ones, IIRC.)

[aduth]

@ockham Yeah, the tests broke after I made the change back to using React.createClass and I had a hard time trying to figure out how to make them work again. The end-result here seemed to fit the bill though.

Generally speaking, I think we should always prefer Component over createClass, so it was the right move. I'm thinking there's something unexpected going on here, as I don't see anything obviously wrong with the refactoring you had done.