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

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.

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.

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.

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.

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

Set to triaged, it is no in the image.

Fixed in oxide 1.10.4-0ubuntu1~overlay1