[chromium] DataTransferItem.webkitGetAsEntry() should synchronously return entry. We were adding DataTransferItem.webkitGetAsEntry(callback) which asynchronously returns FileEntry/DirectoryEntry for drag-and-dropped files, but on the public whatwg ML we got the feedback that this method should synchronously return Entry. (Right now this is only implemented on chromium) http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Apr/0079.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Apr/0111.html
Created attachment 145083 [details] Patch
Adding some more filesystem folks to solicit unofficial review.
Comment on attachment 145083 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=145083&action=review > Source/WebCore/Modules/filesystem/chromium/DataTransferItemFileSystemChromium.cpp:80 > + // FIXME: This involves synchronous file operation. We need to pass file type data when we dispatch drag event. If the file on disk changes during the drag, should calls to webkitGetAsEntry() return current information? If so, you probably can't do this optimization.
Comment on attachment 145083 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=145083&action=review >> Source/WebCore/Modules/filesystem/chromium/DataTransferItemFileSystemChromium.cpp:80 >> + // FIXME: This involves synchronous file operation. We need to pass file type data when we dispatch drag event. > > If the file on disk changes during the drag, should calls to webkitGetAsEntry() return current information? If so, you probably can't do this optimization. Good point, it's a bit questionable. Actually if file<->directory changes we may rather want to return a stale Entry which yields InvalidStateError errors. I'll update the comment and bring it up on the public list.
Committed r119371: <http://trac.webkit.org/changeset/119371>