Context Navigation

Changes between Version 1 and Version 12 of Ticket #11460

Timestamp:

Feb 27, 2014, 11:59:45 AM (10 years ago)

Author:

Piotr Jasiun

Comment:

I created set of samples for problems mentioned above.

Retrieving HTML on dragstart.
- readHtmlOnDragstart.html. Works pretty well. Of course there are some edge cases (like fake selection) but these could be fixed later. I don't see any blocking issues here.
Remembering dragged selection.
- keepDragSelectionWithBookmarks.html. Does not work on Chrome. When you add span on dragstart D&D stop working. Also there would be a problem when user drag element and do not drop it, we need to remove spans then.
- keepDragSelectionWithBookmarks2.html. Works pretty fine, but needs more tests.
- keepDragSelectionWithRanges.html. Works as well. Since document elements does not change during D&D, range seems to be better way to keep drag selection than bookmark2.

Both bookmark2 and range needs to be changed to the bookmark after drop, because we need to create a bookmark for a drop position which can destroy bookmark2 or range.

Retrieving drop position.
- getDropPositionUsingGetSelection.html.
  - On Chrome selection is on the drag, not drop position (but on Chrome we can retrieve drop position easily using different methods).
  - On IE 11 it works fine, selection is on the drop position.
  - On IE 8 it is buggy. Usually selection is in the good position but I found two bugs in a couple of minutes.
- getDropPositionUsingWidgetFunction.html. It is also buggy on IE. The problem is an "unspecified error" from "moveToPosition" (screencast).
- getDropPositionUsingCustomSrcipt.html. Works surprisingly fine on IE9-11 (it is not ported to the IE8 yet).

Legend:

: Unmodified
: Added
: Removed
: Modified

Ticket #11460
- Property Status changed from confirmed to assigned
- Property Owner set to Piotr Jasiun
- Property Summary changed from The editor#drop event - handling dropping content in editor to Handling dropping content in editor

Ticket #11460 – Description

-                      v1
+                      v12
-Part of #11437.
-=== Spec (status: proposal) ===
-. Editor#drop event has to be introduced. It has to be able to carry the same data as a native drop event, so e.g. multiple files as some blobs if spec assumes that (http://www.w3.org/TR/2010/WD-html5-20101019/dnd.html#dnd should be checked to see what's possible). So the first step of normalisation has to be done before firing editor#drop. Alternatively, a wrapped native event may be carried, in which normalisation would be done on demand in its getter methods. The decision has to be made depending on browsers' implementations compatibility. I guess that differences may be so significant that simple wrapper would not make sense. In both cases a class representing new data type has to be introduced, so in fact the final solution may be something between simple wrapper and initial normalisation.
-. After drop was fired, if it wasn't cancelled, editor#paste has to be fired so editor#paste will be the single entry point for content inserted by user.
-. Editor#paste accepts only HTML strings and it seems to be very unsafe to change this. So if non-HTML content has been dropped, it has to be translated to HTML string. For example - dropped image should be translated to '<img src="..." alt="">'. The source will be a reference to a blob carried as additional drop event data (files list). Editor#paste can be fired only if #drop returned a value of HTML type. See point 6.
-. A general idea may be that drop event data is a value-type pair (+ additional value-types pairs for additional files, etc. if that will be required - see 1.) and the translation from non-HTML type to HTML string will mean changing value to HTML string and type to 'html'.
-. The default translation should be done by a #drop listener with high priority (>10) or after #drop. It should be done only if #drop does not yet carry a data in HTML type. This way we'll allow overriding default translation behaviour, by attaching #drop listener performing it earlier. Also, in my opinion it will be better if default translation was done by a #drop event listener too, because it will allow to change something after it happened.
-. We still need to analyse where to put what part of this feature. For example it would be nice if we could add basic dnd support to all standard presets and make the full support with files support optional. The basic part should be able to work without the optional part.
-. Uploading files has to be handled by #paste (because files can be pasted and dropped and #paste is the single entry point). Ticket: #11461.
-. Widgets dnd will have to be aligned to changes made in this ticket. Ticket: #11219.