Opened 10 years ago

Closed 9 years ago

#11219 closed Bug (fixed)

Dragging image2 with caption does not fire paste event

Reported by: Alfonso Martínez de Lizarrondo Owned by: Piotr Jasiun
Priority: Must have (possibly next milestone) Milestone: CKEditor 4.5.0 Beta
Component: UI : Widgets Version: 4.3
Keywords: Cc:

Description (last modified by Piotrek Koszuliński)

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).
  1. 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 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.

Change History (13)

comment:1 Changed 10 years ago by 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.

Last edited 10 years ago by Piotrek Koszuliński (previous) (diff)

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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 and a range, which can be manipulated by event listeners to move the pasted/dropped element to a different position, if necessary?

Version 0, edited 10 years ago by Frederico Caldeira Knabben (next)

comment:5 Changed 10 years ago by Piotrek Koszuliński

Milestone: CKEditor 4.3.2
Status: newconfirmed

@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.

comment:6 Changed 10 years ago by Piotrek Koszuliński

Milestone: CKEditor 4.3.2CKEditor 4.4

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.

comment:7 Changed 10 years ago by Piotrek Koszuliński

Description: modified (diff)
Summary: Dragging image2 without caption fires paste eventDragging image2 with caption does not fire paste event

comment:8 Changed 10 years ago by Piotr Jasiun

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

comment:9 Changed 10 years ago by Piotrek Koszuliński

Milestone: CKEditor 4.4CKEditor 4.5

comment:10 Changed 10 years ago by Piotrek Koszuliński

Description: modified (diff)

comment:11 Changed 9 years ago by Piotrek Koszuliński

Priority: NormalHigh

comment:12 Changed 9 years ago by Piotr Jasiun

Owner: set to Piotr Jasiun
Status: confirmedassigned

comment:13 Changed 9 years ago by Piotr Jasiun

Resolution: fixed
Status: assignedclosed

Done, as a part of #13042.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy