Comment 0 for bug 1500742

On touch devices, this is what happens when a user clicks on a link that triggers a download, or triggers one from the context menu:

 - oxide issues a downloadRequested signal with a URL, and optionally headers, a suggested filename and a mime type
 - the browser instantiates a Downloader component and calls its downloadMimeType() method, which converts the passed mime type to a well-known content type (e.g. ContentType.Pictures) and instantiates a SingleDownload component, passing it the headers and content type
 - the SingleDownload instance, once its gets assigned a unique download ID by the DownloadManager, shows a ContentPeerPicker on screen which uses the passed in content type to prompt the user to choose a target application that will own the downloaded file
 - the actual downloading of the file doesn’t start until the user has picked a target application

This works well if the mime type is known in advance, and can be trusted (indeed a server can lie about the mime types of files it serves). In several cases, the mime type isn’t known in advance (or cannot be trusted), and the browser will outright refuse to download the file because it doesn’t know which application to transfer ownership to.

There must be a way to decouple the actual downloading from the target application selection, so that the mime type is not mandatory information, and users can pick which application to transfer ownership to after the file has been downloaded.