[whatwg] DND: synthetic events

Anne van Kesteren annevk at opera.com
Fri Feb 17 01:33:39 PST 2012


The feedback that follows is based on our implementation experience with  
drag & drop. The people that ought to be credited for the text below are  
Paweł Stanek, Giorgi Chavchanidze, Wilhelm Joys Andersen, and anonymous;  
i.e. not me.


In relation to synthetic events in HTML5 drag and drop, the specification  
currently appears to be incomplete. Therefore our implementation is  
largely based on the most complete existing implementation, the details of  
which are included below. In addition, in the specification has a fairly  
serious oversight in the data store protection.

The spec bases its data store protection on the event type, and not the  
actual dnd status, which would allow (eg.) a dragenter event to create a  
synthetic dragstart event using the existing dataTransfer, and put the  
data store into read/write mode. This then exposes the data store in  
read/write mode to any untrusted page, which is a security issue.

The spec does not provide any way to create a fake data store.

For compatibility with Firefox, we implement the following for the  
initDragEvent method's dataTransfer parameter:
number as dataTransfer must throw an error
string as dataTransfer must throw an error
boolean as dataTransfer must throw an error
object as dataTransfer must create a synthetic dataTransfer

In Firefox, a synthetic dataTransfer seems to be always in protected mode  
(or perhaps just not associated with a drag data store), but Opera creates  
a detatched data store in the expected mode for the synthetic event type.  
This allows a script to synthesise an entire drag event sequence, complete  
with drag data.

Firefox clones only the dropEffect and effectAllowed properties of the  
dataTransfer object when creating a synthetic dataTransfer.

DataTransfer as dataTransfer must reuse the existing data store.

Firefox creates it as a clone of the dataTransfer object - it does not use  
the existing JS object - Opera reuses it so that synthetic events can  
share data with each other (this allows simulation of entire dnd event  
sequences, which may be useful for frameworks).

Real dataTransfer (an actual dnd operation) as dataTransfer should use the  
protection mode from the real dnd, not modify it. This protects against  
the security issue mentioned earlier.

Detatched (synthetic) dataTransfer as dataTransfer should use the  
protection mode from the current event name, not the event where it was  
created.


-- 
Anne van Kesteren
http://annevankesteren.nl/


More information about the whatwg mailing list