[webkit-dev] Behavior of file:// URLs when dragging

[Daniel Cheng]

>From the discussion on https://bugs.webkit.org/show_bug.cgi?id=25882, I
believe the general consensus is that file:// URLs should not be exposed
when dragging and dropping.

Removing file:// URL population from event.dataTransfer is pretty easy;
however, what should we do when the user drops a file in an editable area?
Right now, it creates a link with the file URL, which (I think) defeats the
point of removing file:// URLs from event.dataTransfer. I think the right
behavior here is to return DragOperationNone unless the active target
element is a file input or it's a non-editable element that handles files in
event.dataTransfer, but I'd like to see what other people think first.

On a tangent, I noticed that a lot of implementations of DragData::asURL try
to check that a file URL points at a file that actually exists. What is the
rationale for doing the file existence check in DragData? The loader has to
check for existence anyway, so why not just let the loader do it? This
should save some IO time, especially if the file is on a slow NFS share in
another continent. Does anyone depend on asURL's undocumented behavior to
not return file URLs that point to non-existent files? (If so, I'd be
willing to argue that they shouldn't be doing that anyway.) If not, I'd like
to remove that behavior.

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100510/c2715117/attachment.html>