** 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp