On Mon, May 10, 2010 at 5:48 PM, Daniel Cheng <[email protected]> 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 >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
