Opened 11 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 )
Part of: #11437.
Includes: #12090.
Solution description
- 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).
- 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.
Change History (13)
comment:2 Changed 11 years ago by
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 11 years ago by
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 11 years ago by
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?
comment:5 Changed 11 years ago by
Milestone: | → CKEditor 4.3.2 |
---|---|
Status: | new → confirmed |
@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 11 years ago by
Milestone: | CKEditor 4.3.2 → CKEditor 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 11 years ago by
Description: | modified (diff) |
---|---|
Summary: | Dragging image2 without caption fires paste event → Dragging image2 with caption does not fire paste event |
comment:8 Changed 11 years ago by
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
Milestone: | CKEditor 4.4 → CKEditor 4.5 |
---|
comment:10 Changed 10 years ago by
Description: | modified (diff) |
---|
comment:11 Changed 10 years ago by
Priority: | Normal → High |
---|
comment:12 Changed 9 years ago by
Owner: | set to Piotr Jasiun |
---|---|
Status: | confirmed → assigned |
comment:13 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Done, as a part of #13042.
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:
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.