Download initiated from context menu’s saveLink/saveMedia doesn’t expose a mime type

Bug #1487090 reported by Olivier Tilloy on 2015-08-20
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Canonical System Image
David Barth
Olivier Tilloy
Olivier Tilloy

Bug Description

I’m currently hooking the new WebView.contextMenu API (new in oxide 1.8) in webbrowser-app, and on touch devices where the downloadRequested signal is wired to the ContentHub, I’m consistently getting a message saying that there’s no application installed able to handle this type of content (both for hyperlinks of any type, and images).

This appears to be because the download request initiated by saveLink/saveMedia doesn’t expose a mime type, and thus the content hub fails to associate an application to it.

Related branches

Olivier Tilloy (osomon) wrote :

I just tested with oxide 1.9.0 (from the phablet-team PPA), in the hope that this might be a duplicate of bug #1336611, but it appears it’s not. The issue still exists in 1.9.0.

Olivier Tilloy (osomon) wrote :

Just tested with hyperlinks that embed a mimetype definition (e.g. <a href="file.pdf" type="application/pdf">clickme</a>), this doesn’t improve the situation: the downloadRequested signal is still emitted without a mime type.

Olivier Tilloy (osomon) wrote :

Until I find the time to properly fix that in oxide, I’m going for a workaround in webbrowser-app where I map well-known file extensions to mime types.

tags: added: regression-proposed
Chris Coulson (chrisccoulson) wrote :

I've been thinking a bit about this.

Currently, DownloadRequest will only indicate a mime type for downloads triggered by the Content-Disposition header, as we already have a response for these when the download request fires. But this mime type is really only "meaningful" as part of that response (and even then, the server can quite easily lie about this). As soon as you discard the response and then hand off to an external helper to re-run the request and begin the download (as we do), the mime-type Oxide provides is pretty much meaningless as the remote resource could have changed during this time.

Nothing should be making important decisions like this based on the mime-type that we provide with DownloadRequest, as Oxide doesn't do the actual download. I'm starting to regret exposing the mimetype as part of the DownloadRequest.

Bill Filler (bfiller) wrote :

Raising the priority on this because it causes a bad regression. You can no longer download an image from and open it in the gallery because the mime type is not detected, which causes the peer picker to be empty.

Changed in canonical-devices-system-image:
milestone: none → ww40-2015
assignee: nobody → David Barth (dbarth)
importance: Undecided → High
status: New → Confirmed
Olivier Tilloy (osomon) on 2015-09-29
Changed in oxide:
status: New → Fix Released
assignee: nobody → Olivier Tilloy (osomon)
milestone: none → branch-1.11
Changed in canonical-devices-system-image:
status: Confirmed → Fix Committed
Jean-Baptiste Lallement (jibel) wrote :

Set to triaged, it is no in the image.

Changed in canonical-devices-system-image:
status: Fix Committed → Triaged
Changed in canonical-devices-system-image:
status: Triaged → Fix Committed
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
Changed in canonical-devices-system-image:
status: Fix Released → Triaged
milestone: ww40-2015 → ww46-2015
Changed in canonical-devices-system-image:
status: Triaged → In Progress
Jean-Baptiste Lallement (jibel) wrote :

Fixed in oxide 1.10.4-0ubuntu1~overlay1

Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers