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

[Dmitry Titov]

On Mon, May 10, 2010 at 5:48 PM, Daniel Cheng <dcheng at chromium.org> wrote:

> 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.
>

I think there was a suggestion in that bug to only drop the filename into
the editable area, without the full path. I'm not sure if it is better then
DragOperationNone though.


>
> 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/20100511/db01e3a2/attachment.html>