>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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
