Refine drag and drop events to prevent interference with other drag/drop-sensitive fields in downstream use cases

[NitinBhasneria]

This will improve publiclab/PublicLab.Editor#504.
After this fix, the drag and drop popup will only appear when it drags into proper div. Hence, in the editor module, the unnecessary popup will not appear.
Now if we drag and drop the image in Main Image Module the editor will not have a drag nd drop popup.

In this PR I have added one function that is dragginstopforce() this function will forcibly stop the CSS popup without checking the condition of entre or leave (i.e, it will not check the variable draggingCss===0). This function will be called every time on event mouseout and dragend.
Other than this function the pre-existing function are dragging() called on dragenter this function will add CSS popup including the draggingCss++ , handledragover called on dragover this will add CSS popup including stop(e) and draggingstop() called on dragover.
The flow will be like this:- When the drag enters in the container the dragenter event calls dragging() function after this the dragging in the container will be handled by dragover and on leaving the container the event dragover will call the dragginstop.
In this process is the mouseout or dragend event occurs then draggingstopforce will be called.
Thank you.

[NitinBhasneria]

@jywarren @emilyashley @VladimirMikulic @Shreyaa-s @keshav234156 @Shulammite-Aso.
Have a look.

[VladimirMikulic]

Please document your code.

[NitinBhasneria]

Ok @VladimirMikulic I will add some comment and explanation in short time.

[shreyaa-s-zz]

Can you explain how it works for dragover?

[NitinBhasneria]

@Shreyaa-s by dragover in the container, the function handleDragOver will be called. By this function, the popup CSS, stop(e) cancels the event and e.dataTransfer.dropEffect = 'copy'; will be added.

[keshav234156]

@NitinBhasneria Ok, It works well. Can you please document what each of the function does, so that code becomes easy to understand

[NitinBhasneria]

@keshav234156 yea, cool.
I have edited the main comment on PR.

[jywarren]

This looks great. Just curious about the workflow I proposed in this comment, in terms of how we merge this in! Thank you!

publiclab/PublicLab.Editor#490 (comment)

If you like it, we can open new PRs against those branches and link from here to them, and close this one. Thank you!!!

[NitinBhasneria]

OK, so I am a little confused in the comment @jywarren.
I just want to confirm. According to you, we can directly fork the https://github.com/jywarren/woofmark but you suggest to open a discrete PRs in bevacqua/woofmark.
So here I like your idea. By this we can track the new features and changes in bevacqua/woofmark. Also, wanted to know if xhrOptionsAltBureaucracy is the branch we have to push on?
Also, accordingly, we have to open the PR in both repo jywarren/woofmark and bevacqua/woofmark?

[jywarren]

My apologies for not seeing this earlier! OK - so i pointed this at plots2 branch, and in my comment you referenced, the xhrOptions... branch is not necessary anymore!

Now, that was Oct 25, 2016, but we see that the change it refers to this upstream change in 2017: bevacqua#44 which was merged! So, haha, this is no longer necessary, and we can be building off woofmark v4.2.5 or maybe even v4.2.6, released in 2019.

So we can point the Editor directly at the plots2 branch. Hope that makes sense!

[jywarren]

Also I expanded on the title quite a bit to make it very clear what it achieves. Hope that makes sense!!!

[jywarren]

Great! Looking good!