Editor: Track elements for more reliable drag detection

[aduth]

Fixes #508
Fixes #359

This pull request seeks to resolve an issue where dragging an item could intermittently cause the drag detection to become stuck after moving the cursor away from the page.

Implementation notes:

In my testing, I had found that sometimes the previous implementation would incorrectly become stuck with an inaccurate "drag counter" when multiple consecutive drag incrementing (dragenter) events were triggered on an element. This pull request changes the implementation to track elements known to be dragged over, rather than increment a simple counter. This results in more stable tracking, as even if multiple events were fired against the same element, it would be included in the set of tracked elements only once.

Testing instructions:

The following cases have been observed to have sometimes caused a "stuck":

• Dragging an item across the page, then moving the cursor off the page (while the item is still dragged). This occurs more frequently when the cursor is moved quickly.
• Dragging an item from your finder immediately atop the post editor iframe. There is special treatment for faking a drag event atop the editor iframe.

Verify that drag detection is tracked correctly in your preferred browser.

1. Navigate to the Calypso post editor
2. Select a site, if prompted
3. Drag an item from your finder over the page
4. Note that the "drop zone" is shown in a deactivated state while the item is dragged over the page
5. Continue dragging the item over the drop zone area
6. Note that the drop zone becomes activated
7. Continue dragging the item off the drop zone area
8. Note that the drop zone becomes deactivated
9. Continue dragging the item off the page
10. Note that the drop zone area is hidden

[kellychoffman]

👍

[timmyc]

I think I may have found a little edge case here, but verified it breaks in production too - so I suppose this could be fixed here since it is on-topic or in a subsequent PR.

I can get the drop-zone "stuck" by doing the following - tested in Safari only:

• Drop a larger image on the editor
• While it is still uploading, drag another image over the editor, and then drag it away
• Dropzone is still highlighted/stuck

Note these images are on my desktop, but I also did notice it with the dragging from my downloads drawer in the dock :)

[gwwar]

👍 Looks good.

I assume there were some issues using the dragend event? If that's the case, I would also suggest adding a mouseup handler on your iframe/dropzone to clear out drag state in case the editor gets into a stuck state.

[aduth]

Thanks for the reviews, @timmyc and @gwwar !

@timmyc : Can you try again with 85fff41 ? I suspect what was happening is that the dragover atop the temporary image was captured, but since we were not previously tracking mutations to the DOM, the set of tracked drag elements was not updated when the temporary element was removed from the page. 85fff41 introduces a MutationObserver to untrack removed nodes.

@gwwar : If I recall correctly, I had seen that sometimes multiple of the same events were being fired consecutively, which seems like buggy browser behavior. Regardless, I think this is a much more reliable approach than simply incrementing and decrementing a counter based on the events received. Your suggestion of resetting the state on mouseup is a good one, and ensures that even if it ever manages to get stuck in the future, a user could simply click on the page to un-stick it. See 74d26d7.

[gwwar]

@aduth 👍 confirmed that mouseup unsticks the blue dropzone. This can be tested with FF and pressing esc to cancel the drop event, to get the editor into a stuck state. A mouse click on the editor will remove the blue dropzone.

Being able to unstick the editor is good enough to 🚢 in my opinion. There will likely be other corner cases/browser combos that trigger this.