touch-packages team mailing list archive

[Olivier Tilloy <olivier.tilloy@xxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: content-hub (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: ubuntu-download-manager (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: webbrowser-app (Ubuntu)
     Importance: High
         Status: Triaged

** Also affects: content-hub (Ubuntu)
   Importance: Undecided
       Status: New

** Also affects: ubuntu-download-manager (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to webbrowser-app in Ubuntu.
https://bugs.launchpad.net/bugs/1500742

Title:
  Downloading a file requires its mime-type in advance

Status in content-hub package in Ubuntu:
  New
Status in ubuntu-download-manager package in Ubuntu:
  New
Status in webbrowser-app package in Ubuntu:
  Triaged

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1500742/+subscriptions