[Chrome] Drop position invisible

[Piotrek Koszuliński]

There's no caret visible when dragging. Most likely caused by preventing dragover which I don't know why we do.

[Piotr Jasiun]

I introduced preventing dragover in #12264, because without it, when user drop the file, the file path will became an URL and user will lose content. As long as I know there is no other way to prevent this behavior (drop event is too late). The problem is that we lose cursor at the same time. But...

On Chrome and Firefox

Fortunately this is only IE problem, do not need to prevent dragover on non-IEs.

On IE 10+

The problem is only with file dropping. We have no files available on dragover, but we can check in dataTransfer.types if it is file, so we can prevent default dragover only in these cases. We have no cursor when we drop file on IE anyway so we lose nothing.

On IE 9-

Unfortunately old IEs does not support file API and we are not able to check if it is file or text. What is even worst preventing default dragover breaks whole drag & drop badly (drop position is incorrect) on IE9. Fortunately old IEs does not support file API, so this is not our problem. IE9- users should not drop files into the browser because it is not supported there. If they do it, they will get the same result as in CKEditor 4.4: the URL will be replaces with file path.

To sum up, I changed the method so now preventDefault is called only on IE10+, only if the file is dragged.

Changes in ​t/12421.

[Piotrek Koszuliński]

Sounds great and terribly at the same time :) Thanks for the analysis.

[Piotrek Koszuliński]

I reported a bug for this issue: ​https://connect.microsoft.com/IE/feedbackdetail/view/985422/contenteditable-the-drop-event-isnt-fired-when-dropping-file-in-contenteditable

The problem here is that drop isn't fired and definitely should be.

[Piotrek Koszuliński]

Fixed on major with ​git:039a91a.