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
--
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
