[IE9-11] Dropped content is often inserted at selection position from before DnD

[Piotrek Koszuliński]

Reproducible on ​http://tests.ckeditor.dev:1030/tests/plugins/clipboard/manual/draganddrop when dropping from outside of the editors. First DnD works, but second no - content is inserted in the wrong place (previous selection position).

[Piotrek Koszuliński]

I raised priority of this ticket because this bug is very visible in the dnd sample in SDK.

[Piotrek Koszuliński]

I pushed ​branch:t/13472. The fix is pretty simple - we stop using existing selection. Instead, we use the tricky mechanism that we created for IE8. From my tests I can see that it's much better. It does not work in some specific cases, as we know, but it does not fail when dropping from outside the editor. I'm worried only that we'll be now using it for all kinds of DnD, and the previous method worked better for internal DnD. So alternative patch may be to check data source.

[Piotrek Koszuliński]

I pushed ​branch:t/13472b with what I think is a better fix. I noticed that focus is force in the editor and this cause automatic restoring of a previous selection. The fix was to remove that line, but then it turned out that external DnD does not work on IE8. So I moved the editor.focus() call to the method that we use on IE8.

[Piotrek Koszuliński]

Another case:

• select a widget inside editor,
• try DnD a link into this editor, but with only single mousedown (it means - do not select it before DnD - just drag it).

It totally fails (error is thrown). The reason is that getRangeAtDropPosition returns a range inside the fake selection container.

[Piotrek Koszuliński]

Pushed more commits to ​branch:t/13472b. Back to my previous idea that if editor is not focused then it's better to use the second mechanism.

[Szymon Cofalik]

IE11: Passed

IE10:

• Classic editor: content is pasted always in first <h1> element (After phrase "Apollo 11").
• Inline editor: works like before fix. It almost seems like the cache problem but I checked and new sources are linked
• Dragging link with widget focused does not throw error (still problems descripted above apply)

I will now test IE9 and IE8.

[Szymon Cofalik]

IE9: Dragging link with widget focused into editor's editabgle is impossible, however you can still drag into widget's editable and it works.

Edit: there is a bit more to link dragging. Even when editor's editable is focused I can't drop link into it. The cursor changes into crossed circle. Also, sometimes, when I hover mouse cursor on widget, the cursor changes back and when I drop into editor's editable whole browser crashes (it happens only sometimes so it might be because I open it on VM).

IE8: Same like IE9 but not crashing.

Note: DnD on IE8-IE10 works only with console open: probably because of console.log()s in those tests.

[Piotrek Koszuliński]

Edit: there is a bit more to link dragging. Even when editor's editable is focused I can't drop link into it.

Link dragging is not supported until IE10. It is a native thing. And about the crashes... nothing we can do.

Note: DnD on IE8-IE10 works only with console open: probably because of console.log()s in those tests.

Yes - and you should never test with the console closed :P

Classic editor: content is pasted always in first <h1> element (After phrase "Apollo 11").

Inline editor: works like before fix. It almost seems like the cache problem but I checked and new sources are linked

Dragging link with widget focused does not throw error (still problems descripted above apply)

I cannot reproduce these issues... And I don't understand what the second point mean.

[Szymon Cofalik]

Inline editor: fix haven't changed anything - content is dropped at the first drop position (or rather at the position of last known selection/caret position).

[Artur Delura]

Related: #13443

[Piotrek Koszuliński]

IE10: Classic editor: content is pasted always in first <h1> element (After phrase "Apollo 11")

Turned out this works fine in some IE10 versions, but fails in some other ones. Still, the patch seems to fix IE9 and IE11 (and some IE10 versions), so taking into account that the problem with IE10 is only with external paste, it would be worth including.

[Piotr Jasiun]

After the investigation we found out that that fix does not work only on some of the IE 10 versions (10.0.9200.16736) and is fine on others. Also the situation is better on IE 9 and IE 11 then it was before. Because the fix touch only external drops which were bad anyway it should not break anything. We decided to close it and include in version 4.5.0.

​git:6beaee9