directory-upload
directory-upload copied to clipboard
WICG
Consider how we could avoid the I/O blocking for FILE picking in addition to directory picking
We should consider we could avoid the I/O blocking for FILE picking in addition to directory picking. One way might be to allow getFilesAndDirectories to be used when a file (not directory) picker is used. By that I'm referring to the importance of setting .files to null, as described in issue #8. We could let content opt-in to this by adding an 'async' attribute to their input element, say, or some other means for authors to flag to the UA that they will use getFilesAndAttributes instead of .files and so get earlier, non-IO-blocking firing of the 'change' event.
We should consider this now since the mechanism that we choose may impact on the API for directory picking itself.
Another way to fix this might be to introduce a 'willchange' event. This event would not fire when the picker is opened, but would rather fire after the user clicks "OK" to make a selection but before any I/O has occurred as described in issue #8.
This is an example of an approach to solving the problem for file picking that might impact on the API we'd prefer to have for directory picking. If we introduced a 'willchange' event then there wouldn't be any need for nulling out .files and having the Promise returning 'HTMLInputElement.getFilesAndDirectories' since that behavior and API exists to solve the blocking I/O problem (as described in issue #8).
If I understand you correctly, the use case for this is:
- The directory attribute is set on input type, also making .files null per issue #8 .
- A file picker is still used, and not a directory picker.
I'm not sure right now about the situations where 2. arises. Can you shed some light on this? Unless I'm misunderstanding you, won't older codebases ignore the directory attribute and resort to business as usual?
@arunranga No, I'm talking about solving the blocking I/O issue for normal file picking. So no directory attribute.
So basically if we took the suggestion from my second comment normal file picking would be exactly the same, except that there would be a 'willchange' event fired before the blocking I/O starts happening to gather stat info for the FileList's items.