Mozilla aims to grow the Web platform and make it accessible on all new devices by reducing the Web’s dependency on Flash. A flash-free web is a long ways away but they’re taking it one step at a time. The latest project Mozilla has taken up was initially proposed by Microsoft and is in line with their efforts to standardize and expose the useful features that are, at present, only available on Flash to the whole Web.

Currently there is no standard solution to handle directories and scenarios that consist of a combination of files and directories.

The new project, Directory Upload, is a sectional generalization of a much more comprehensive FileSystem API draft. Directory Upload offers directory picking and directory drag-and-drop functionality without Flash.

In this article, we’ll cover Mozilla’s flash-free Web projects and discuss Directory Upload in detail. We will also go over its expected behavior from a coding perspective.

Let’s get started.

Mozilla’s Flash-Free Web

Mozilla’s vision of a flash-free web has one simple motivational factor driving it – to make the Web accessible on all new devices. Mozilla pulled the plug on Adobe Flash earlier this year by temporarily blocking it on Firefox after vulnerability concerns leading to a critical security flaw rose.

In this struggle, Mozilla has released several add-ons like No Flash and Video WithOut Flash for Firefox browsers. A flash-free clipboard for the Web is also underway which implements execCommand for cut / copy. Mozilla’s implementation of Directory Upload is another step in the right direction for the Web.

Many sites are making similar efforts by replacing Flash-based content with HTML5-based content support. For instance, you can use YouTube videos without Flash by opting for their non-Flash video player. Occupy Flash shares Mozilla’s dream of ridding the Web of Flash once and for all.

What’s So Bad About Flash?

The Flash Player is holding the Web back from becoming responsive and scalable by making it less accessible. Flash requires frequent security updates and bug fixes, it’s doesn’t work on most mobile devices which leads to a poor user experience for the growing number of Web users who don’t use traditional desktop browsers.

In short, Flash is outdated technology and it hinders the Web. Mozilla’s efforts in this regard make a lot of sense because as long as we have outdated technology running on our systems, we will keep developing code for it and not be able to accept modern Web standards.

Before we move on to Directory Upload’s behavior let’s look at one of the more popular directory upload technologies in existence and the mechanism behind it.

Chrome’s webkitdirectory

The mechanism behind Chrome’s webkitdirectory is that all the files under the entire expanded directory tree are included as File objects to a single FileList, that is flat hierarchically, when a user selects a directory. The FileList is set on <input> element once it’s been added.

This means that prior to firing the change event the whole directory tree must be traversed. Firing the change event will inform the page of the user’s selection and file availability. The advantage of this approach is that it ensures that all conventional libraries and scripts can effortlessly be made to work properly because they expect a flat list back from <input>.

The disadvantage, however, outdoes the advantage of using the FileList approach.

Suppose that the expanded directory contains a large number of files. Even if the I/O operations per second (IOPS) is high; the page will be notified that the user selected a directory after a significant amount of time. The other downside is that the machine could hang before the event is fired if it runs out of memory.

The bottom line is that the page becomes aware of the user’s selection only when the change event notifies it. And until the event is fired the page doesn’t know that there are incoming events. This leads to the conclusion that the entire process will be tremendously slow if:

  • The machine’s IOPS is low.
  • The user selects a large directory tree.

For this very reason, standardizing webkitdirectory attribute’s behavior for the <input> element is out of the question even though it would ultimately make it simpler for authors to update existing content that utilizes webkitdirectory to support all browsers (not just Chrome 11).

Having said this, let’s take a look at the Directory Upload proposal’s intended behavior and the results it gives.

Mozilla’s Directory Upload

The webkitdirectory attribute’s behavior and the Directory Upload proposal are different in that Directory Upload provides a Promise that an array of the immediate File / Directory objects that were selected by the user fulfills. In short, the HTMLInputElement.files is replaced with the array that fulfills the Promise.

This approach eliminates the delay that was caused due to selection of a large directory tree or low IOPS. Instead of waiting for the event to fire, the page can begin processing the directory a user picks and return feedback/acknowledgement to the user faster.

Since the initial Promise only accessed immediate File / Directory objects, in order to access a Directory’s direct contents on demand we would have to instigate yet another Promise returning method. The newly set off Promise would cause the page to iteratively traverse the directory tree, processing and returning feedback as it goes down the expanded directory.

Directory Interface in the main API looks like this right now: – name of the directory

Directory.path – relative path of the directory

Directory.getFilesAndDirectories – if the directory has files / sub-directories it returns a Promise with a sequence of File / Directory else if the directory is empty, it returns a Promise with an empty sequence.

Here’s the API’s File Input mechanism: – file input can accept directories if input type is “file” and is TRUE.

Drag-and-drop functionality is implemented through the DataTransfer interface:

DataTransfer.getFilesAndDirectories – if the directory has files / sub-directories it returns a Promise with a sequence of File / Directory else if the directory is empty, it returns a Promise with an empty sequence.

While experimenting with this API on Nightly builds keep in mind that HTMLInputElement.getFilesAndDirectories returns a Promise that changes every time the directory picker is accessed. The order in which you make the calls is important here. Fire the change event before you call HTMLInputElement.getFilesAndDirectories method to avoid any problems.

Why Don’t We Use .Files Method?

A logical question that some of you might have at this point is that why do we even bother with the HTMLInputElement.getFilesAndDirectories method when we could store Directory objects into a FileList returned by the HTMLInputElement.files method. The HTMLInputElement.files method can be used alternatively if the user directly picks any given directory.

The answer to this question is that we adopt the HTMLInputElement.getFilesAndDirectories method in order to be able to fire the change event as soon as possible to make the page aware of the user’s selection. Generally, the OS specific file pickers and directory pickers are the ones that notify the browser by making a list of paths available.

We don’t use the HTMLInputElement.files to send the selected files and directories because firing the change event at that point would involve the script to iterate on FileList which, in some cases, necessitates I/O. Therefore, Directory Upload lets the change event to be fired immediately once the OS specific picker provides its list of paths instead of waiting for the full list of objects to be created. All of this is possible only when we require HTMLInputElement.files to be null during the time the file or directory picker is being used.

I/O needed to create the File / Directory objects for the Promise can occur asynchronously once the change event has been fired.

Uploading Directories With Directory Upload

As of now, Directory Upload requires users to submit the files under a selected directory if it’s <input> is contained in a <form> and wrapping the <input> with <form> should be avoided. Uploading a directory generally means that there is a large number of files in it. A large number of files is directly proportional to the amount of time a submission will take.

The downside of uploading a large number of files via a single directory is that the chances of hitting the server limit are high. In such a case, the directory will fail to upload.

The author can adopt the following steps avoid such circumstances:

  1. Traverse the directory tree incrementally.
  2. Use XMLHttpRequest to upload files in small batches or
  3. Use a JavaScript library to upload files in small batches.

Wrapping It Up

The Directory Upload proposal is still under testing stages and Mozilla requests that users and developers experiment with it on their Nightly build and provide feedback to WICG mailing list to speed up the process. Once all bugs are fixed, Directory Upload will be shipped.

In this article, we covered the need for a new directory picking and drag-and-drop API to standardize for the Web. We covered the differences between Chrome’s webkitdirectory and Mozilla’s Directory Upload. To conclude, we urge you to test out the proposed API on Mozilla’s Nightly build and provide the developers with your personal feedback.

Do you agree that the Web needs a standardized directory picking and drag-and-drop API? What are your thoughts on a flash-free Web? Let us know in the comments section below.