id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc 11460,The editor#drop event - handling dropping content in editor,Piotrek Koszuliński,,"Part of #11437. === Spec (status: proposal) === 1. 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. 2. 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. 3. 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 ''. 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. 4. 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'. 5. 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. 6. 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. 7. Uploading files has to be handled by #paste (because files can be pasted and dropped and #paste is the single entry point). Ticket: #11461. 8. Widgets dnd will have to be aligned to changes made in this ticket. Ticket: #11219.",New Feature,confirmed,Normal,CKEditor 4.4,General,,,,