- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 17 Feb 2012 10:33:39 +0100
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/
Received on Friday, 17 February 2012 01:33:39 UTC