Chrome's implementation of FileSystemFileEntry.file

[Troy Corbin]

Hello all,

I apologize if this is not the appropriate forum for this issue.

I'm developing a drag and drop file upload that retains folder structures. I'm having an issue with Chrome's implementation of FileSystemFileEntry.file. Specifically, the FILE object it returns does not contain the webkitRelativePath property. Without this property, and with the asynchronous nature of FileSystemFileEntry.file, it is very difficult to associate the FILE object with the file's relative path contained in the FileSystemFileEntry.

I am currently working around this by having a global scope Object contain an associative array of filenames to paths. However this fails when the file structure contains multiple files with the same name. We really need to have webkitRelativePath returned as a part of the FILE object.

[Joshua Bell]

Chrome unhelpfully has basically two competing APIs when dealing with file/directory uploads.

If the webkitdirectory attribute is specified, the files in the inputs's files collection have webkitRelativePath populated and webkitEntries is not. 

If webkitdirectory is not specified, the files will not have webkitRelativePath populated but webkitEntries will be on the drop event / webkitGetAsEntry on the DataTransferItem will return an entry. The entry hierarchy can be used to reconstruct paths via traversal.

(There's also inconsistency between drag&drop action vs. clicking and selecting files.) 

There are a handful of bugs tracking these e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=138987

Now that other browsers (Edge, Firefox) are implementing support here we're planning to do some clean-up work. 

On Tue, Sep 20, 2016 at 3:49 PM, Troy Corbin <tco...@countrybrookdesign.com> wrote:

Hello all,

I apologize if this is not the appropriate forum for this issue.

I'm developing a drag and drop file upload that retains folder structures. I'm having an issue with Chrome's implementation of FileSystemFileEntry.file. Specifically, the FILE object it returns does not contain the webkitRelativePath property. Without this property, and with the asynchronous nature of FileSystemFileEntry.file, it is very difficult to associate the FILE object with the file's relative path contained in the FileSystemFileEntry.

I am currently working around this by having a global scope Object contain an associative array of filenames to paths.

If you have the path (presumably via entry hierarchy traversal), why not just assign it to the File object? Why bother with the indirection via a map?

 

However this fails when the file structure contains multiple files with the same name. We really need to have webkitRelativePath returned as a part of the FILE object.

--
You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-html5+unsubscribe@chromium.org.
To post to this group, send email to chromiu...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Troy Corbin]

On Tuesday, September 20, 2016 at 10:16:56 AM UTC-5, Joshua Bell wrote:

Chrome unhelpfully has basically two competing APIs when dealing with file/directory uploads.

If the webkitdirectory attribute is specified, the files in the inputs's files collection have webkitRelativePath populated and webkitEntries is not. 

If I recall correctly ( I tested this several days ago ) specifying webkitdirectory did not provide webkitRelativePath for me. I attributed this to one of two factors: 1) My drop zone is on a DIV element not an INPUT, or 2) webkitdirectory does not function for drag and drop. Not sure which is the deciding faction, I didn't test further.

 

If webkitdirectory is not specified, the files will not have webkitRelativePath populated but webkitEntries will be on the drop event / webkitGetAsEntry on the DataTransferItem will return an entry. The entry hierarchy can be used to reconstruct paths via traversal.

Correct. I am using webkitGetAsEntry / createReader / readEntries to read the folder structure.

 

(There's also inconsistency between drag&drop action vs. clicking and selecting files.) 

There are a handful of bugs tracking these e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=138987

Now that other browsers (Edge, Firefox) are implementing support here we're planning to do some clean-up work. 

Awesome, that's good to know that it will get some love. Though with the age of the bug you linked, I get the feeling this might not be a priority.

 

On Tue, Sep 20, 2016 at 3:49 PM, Troy Corbin <tco...@countrybrookdesign.com> wrote:

Hello all,

I apologize if this is not the appropriate forum for this issue.

I'm developing a drag and drop file upload that retains folder structures. I'm having an issue with Chrome's implementation of FileSystemFileEntry.file. Specifically, the FILE object it returns does not contain the webkitRelativePath property. Without this property, and with the asynchronous nature of FileSystemFileEntry.file, it is very difficult to associate the FILE object with the file's relative path contained in the FileSystemFileEntry.

I am currently working around this by having a global scope Object contain an associative array of filenames to paths.

If you have the path (presumably via entry hierarchy traversal), why not just assign it to the File object? Why bother with the indirection via a map?

The File object is created asynchronously with FileEntry.file and is not returned. Instead I have to supply a callback. I know of no way to directly pass the path into the callback function, though that could just be my limited Javascript knowledge.

 

 

However this fails when the file structure contains multiple files with the same name. We really need to have webkitRelativePath returned as a part of the FILE object.

--
You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-html...@chromium.org.

[Joshua Bell]

On Tue, Sep 20, 2016 at 4:39 PM, Troy Corbin <tco...@countrybrookdesign.com> wrote:

On Tuesday, September 20, 2016 at 10:16:56 AM UTC-5, Joshua Bell wrote:

Chrome unhelpfully has basically two competing APIs when dealing with file/directory uploads.

If the webkitdirectory attribute is specified, the files in the inputs's files collection have webkitRelativePath populated and webkitEntries is not. 

If I recall correctly ( I tested this several days ago ) specifying webkitdirectory did not provide webkitRelativePath for me. I attributed this to one of two factors: 1) My drop zone is on a DIV element not an INPUT, or 2) webkitdirectory does not function for drag and drop. Not sure which is the deciding faction, I didn't test further.

webkitdirectory only applies to an input element, so yep - that would explain it.

 

 

If webkitdirectory is not specified, the files will not have webkitRelativePath populated but webkitEntries will be on the drop event / webkitGetAsEntry on the DataTransferItem will return an entry. The entry hierarchy can be used to reconstruct paths via traversal.

Correct. I am using webkitGetAsEntry / createReader / readEntries to read the folder structure.

 

(There's also inconsistency between drag&drop action vs. clicking and selecting files.) 

There are a handful of bugs tracking these e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=138987

Now that other browsers (Edge, Firefox) are implementing support here we're planning to do some clean-up work. 

Awesome, that's good to know that it will get some love. Though with the age of the bug you linked, I get the feeling this might not be a priority.

It hasn't been in the past. Hope to change that, but no guarantees. Feedback like this is helpful!

 

 

On Tue, Sep 20, 2016 at 3:49 PM, Troy Corbin <tco...@countrybrookdesign.com> wrote:

Hello all,

I apologize if this is not the appropriate forum for this issue.

I'm developing a drag and drop file upload that retains folder structures. I'm having an issue with Chrome's implementation of FileSystemFileEntry.file. Specifically, the FILE object it returns does not contain the webkitRelativePath property. Without this property, and with the asynchronous nature of FileSystemFileEntry.file, it is very difficult to associate the FILE object with the file's relative path contained in the FileSystemFileEntry.

I am currently working around this by having a global scope Object contain an associative array of filenames to paths.

If you have the path (presumably via entry hierarchy traversal), why not just assign it to the File object? Why bother with the indirection via a map?

The File object is created asynchronously with FileEntry.file and is not returned. Instead I have to supply a callback. I know of no way to directly pass the path into the callback function, though that could just be my limited Javascript knowledge.

You can use a helper like this to hold the path then apply it.

function getFile(entry, path, successCallback, errorCallback) {

  entry.file(function(file) {

    file.extra_path_property = path;

    successCallback(file);

  }, errorCallback);

}

 

 

However this fails when the file structure contains multiple files with the same name. We really need to have webkitRelativePath returned as a part of the FILE object.

--
You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-html...@chromium.org.
To post to this group, send email to chromiu...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

--
You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-html5+unsubscribe@chromium.org.

[Troy Corbin]

Wow, I never considered further abstraction as a fix but it works beautifully. Thank you very much Joshua for the advice!