This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Please consider adding a FileList constructor. I think it should take a sequence<File> argument, for consistency with the File constructor. Motivation: when combined with the File constructor and with a read-write "files" property on the HTMLInputElement (see Bug 17125), this is sufficient to implement any changes to the list of files that an <input type="file"> would upload. For example, Bug 17125 can be implemented by creating a new FileList that contains all the Files in the old list, except for the one that should be removed. Security implications: there shouldn't be any, as it already is possible to create a FileList in a round-about way, by adding File instances to a DataTransfer [1] via items.add(File) and reading the files attribute. This is already used in the wild [2]. Also, this proposal leaves FileList immutable, which might simplify some correctness / security analysis. Alternatives: Bug 24586 proposes removing FileList altogether, but it relies on Bug 23682, which requires significant changes and thinking. The approach suggested here can be implemented now. If the JS array succeeds, the FileList constructor can be deprecated at the same time as the items() method. Thank you! [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/user-interaction.html#datatransfer [2] http://crbug.com/360308
I do not think we should encourage the use of FileList any more, and should instead just get cracking on bug 24586. Both this suggestion and that one will require work.
(In reply to Domenic Denicola from comment #1) > I do not think we should encourage the use of FileList any more, and should > instead just get cracking on bug 24586. Both this suggestion and that one > will require work. I agree with this, but it does mean that features that are FileList-like are gated on a bunch of underlying WebIDL issues. We'll need to roll up the sleeves and solve those. If we agree that the long term direction is to remove a standalone FileList object (and I think we do agree on this), then adding or enhancing the API footprint of FileList (e.g. adding a constructor) seems like bandaid on gangrene to me. It's a good suggestion, though; the bug description is certainly the solution to a few issues like fixing badly queued selections in favor of correct subsets.
(In reply to Domenic Denicola from comment #1) > I do not think we should encourage the use of FileList any more, and should > instead just get cracking on bug 24586. Both this suggestion and that one > will require work. I agree with your statement. However, I think that, while it is true that both this suggestion and bug 24586 require work, the amount of work that they require is vastly different, both for spec editors and implementers. I also think that the difference can translate into holding back this feature from apps and frustrating developers for years, and pushing them to other platforms.
Migrating legacy File API bugs to GitHub issues. Please open a GitHub issue on File API if you think https://github.com/w3c/FileAPI/issues/19 is insufficient.