touch-packages team mailing list archive

[Olivier Tilloy <olivier.tilloy@xxxxxxxxxxxxx>]

** Description changed:

  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
+  - 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.
+ 
+ ========================================================================
+ 
+ Steps to observe the issue (from bug #1510187):
+ 
+ 1. Go to <https://bugzilla.mozilla.org/show_bug.cgi?id=299372>.
+ 2. Scroll down to the "Attachments" list.
+ 3. Long-tap on "An idea for a good solution".
+ 4. Choose "Save link".
+ 
+ What happens: "Sorry, there aren't currently any apps installed that can
+ handle this type of content."
+ 
+ What should happen: The Gallery is offered as an app to save the image
+ to.

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

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

Status in content-hub package in Ubuntu:
  Confirmed
Status in ubuntu-download-manager package in Ubuntu:
  Confirmed
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.

  ========================================================================

  Steps to observe the issue (from bug #1510187):

  1. Go to <https://bugzilla.mozilla.org/show_bug.cgi?id=299372>.
  2. Scroll down to the "Attachments" list.
  3. Long-tap on "An idea for a good solution".
  4. Choose "Save link".

  What happens: "Sorry, there aren't currently any apps installed that
  can handle this type of content."

  What should happen: The Gallery is offered as an app to save the image
  to.

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