I agree,
IE and Firefox dispatches the drop event for both form controls and
contentEditable even if dragover isn't canceled. They insert the dropped
data unless drop event is canceled.
WebKit (Windows) inserts the dropped data but doesn't fire the drop event.
If dragover is canceled, then
As you stated, both IE and Safari have this thing pretty nailed down for
quite a while now already.
Both IE and Safari are quite buggy when it comes to drag-and-drop
actually, at least compared to what the spec says (especially IE).
Firefox has done a considerable amount of work to implement
For future reference, I posted another suggestion to the public-webapps
list. Instead of specifying a download URL, you could specify a URL on a
type as the source of the data:
dataTransfer.setRemoteData(mimeType, url);
That could allow for both file downloads and/or lazy loading of data
/large-object-storage-for-nhibernate-and-ddd-part-1-blobs-clobs-and-xlobs/
.)
I'm not sure I like this though because the complexity involved compared to
a DownloadURL-format. But there is a need to be able to do this with
client-generated data as well.
Sebastian Markbåge
On Tue, Aug 18, 2009 at 10
The spec should explicitly specify which MouseEvent properties are
available during the various drag events to avoid assumptions.
The spec requires them to all be set on all drag events, currently.
I thought that this was clear too but apparently it's not clear that they
should be set to
Jonas,
That is my interpretation too. But I think it's a little unclear whether
that means that the UA should update any Location fields in the UI. I
understand that this may be optional or outside the scope, but I think that
it should still be mentioned.
Now if the UA is suppose to update the
.
On Thu, Jul 30, 2009 at 4:27 PM, Sebastian Markbåge
sebast...@calyptus.euwrote:
Jonas,
That is my interpretation too. But I think it's a little unclear whether
that means that the UA should update any Location fields in the UI. I
understand that this may be optional or outside the scope, but I
2) For multi-process browsers like Chrome, there seem to be limitations as
to what can actually be accessed between processes (direct DOM access across
process boundaries seems problematic for example). Do you have ideas about
how to address this, since assumedly the page calling
The spec should explicitly specify which MouseEvent properties are available
during the various drag events to avoid assumptions.
Gecko currently sets pageX, clientX, screenX etc. to zero on the source node
events (drag, dragend).
As far as I know there are no known security flaws surrounding
