Dragging image2 with caption does not fire paste event

[Alfonso Martínez de Lizarrondo]

Part of: #11437.

Includes: #12090.

Solution description

1. Editor#paste event has to be modified so it inserts content into passed (as a data property) range or current selection. This is required, so it will be possible to drop between blocks (required by block widgets dnd).

2. Widgets has to fire editor#drop and finalize their entire dnd process only by using this event. Currently we just move DOM element when dnding block widget, but we need to change this, so inline and block widgets dnd will work the same way.

Original ticket description

Using Firefox (other browsers untested), open ​http://ckeditor.com/demo#widgets and set in the console a listener for paste:

CKEDITOR.instances.editor2.on('paste', function() { alert("pasted")})

Test that it works with Ctrl+C, Ctrl+V, Ok so far.

Now drag the image widget. The magic line appears and everything works fine.

Then edit the image and disable the "Captioned image" in the dialog.

Now when the image is dragged, the magic line doesn't appear and a paste event is fired upon drop, the HTML seems to include the whole widget.

Using the normal editor everything works fine, no paste is fired for dragging an image around.

[Piotrek Koszuliński]

Yes, this is on purpose and it was consistent when I implemented that. Every DnD operation with widgets caused paste event. It stopped to be consistent when we implemented block widgets DnD with lineutils.

The reason why I think DnD (all kinds of DnD in the future) should fire paste event is that this becomes a single entry point for content inserted directly to the editable. So if e.g. editor is configured to force paste as plain text, then if someone DnDed an HTML from outside the editor, that HTML will be "textified". So there will be an equality between pasting and dropping content.

However, we're talking here about DnDing inside editor, which could behave differently. But on the other side distinguishing between dragging from outside editor and within it would be tricky. Also, paste event is fired always - no matter what's the source of the data.

Therefore, what's wrong here IMO, is that block widgets DnD does not fire paste event. If we fixed that we would have consistent and hermetic input filtering and two problems:

1. it's odd for DnD to fire paste event,
2. in case of block widgets DnD, the selection would have to placed between blocks, what's not possible, so some hack would have to be used.

I had doubts before about using paste event, now (when block widgets are DnDed differently) I have more, but I still see a need to single entry point.

So I'm afraid that we may need a complex solution. A new event ("input" maybe), which would inherit some behaviours from paste event (e.g. textifying and paste from word filters), but could be used by the original "paste" event and a new "drop" event and would not insert content itself (it would do only filtering), so "drop" won't be limited to selection (block widgets scenario).

I'll ask others for opinions.

[Piotr Jasiun]

In my opinion DnD is the same as Ctrl+C & Ctrl+V (just using mouse instead of keyboard) and it should behave similarly. Keep it simple. We have paste event if user copy and paste content inside editor so we should have the same event on DnD.

[Alfonso Martínez de Lizarrondo]

Certainly DnD is almost like Cut&Paste, but the behavior shouldn't be different if the widget is in one mode or the other.

And until you handle drop for the native DnD, it seems strange that only a certain type of drop fire a paste event. I've been working for several days trying to bring compatibility with the image2 widget and I didn't notice this behavior until yesterday and it could have gone completely unnoticed unless I didn't want to test other unrelated changes and I noticed an error.

So if you prefer it this way: Please unify DnD logic for widgets so they behave the same way whether they are captioned or not.

[Frederico Caldeira Knabben]

I think that using the "paste" event for it makes sense. It'll help simplify things.

So, what if we would send the paste/drop point to the event unified as a range, which can be manipulated by event listeners to move the pasted/dropped element to a different position, if necessary?

[Piotrek Koszuliński]

@alfonsoml: Consistency is definitely our goal. Paste event not being fired after DnD of block widget is a side effect of a last minute change and we'll fix this in 4.3.2.

Firing paste event on native DnD would have to wait longer, because we miss entire DnD support, but I predict that it'll happen in 4.x.

@fredck: I had this idea on the tips of my fingers, but it vanished :D. Yes - the data-range-mode trio seem to be well founded.

[Piotrek Koszuliński]

I changed my mind a little bit. Let's have it fixed in 4.4 together with the DnD support on which we'll work. Otherwise we risk working on this twice.

[Piotr Jasiun]

For sure it is related with #11437, but I'm not sure if it is part of it.

[Piotrek Koszuliński]

See ​http://dev.ckeditor.com/ticket/11437#comment:14.

[Piotr Jasiun]

Done, as a part of #13042.