Download initiated from context menu’s saveLink/saveMedia doesn’t expose a mime type
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Canonical System Image |
High
|
David Barth | ||
| | Oxide |
Undecided
|
Olivier Tilloy | ||
| | 1.10 |
Undecided
|
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
- Ken VanDine: Approve on 2015-08-27
- Ugo Riboni (community): Approve on 2015-08-27
- PS Jenkins bot: Approve (continuous-integration) on 2015-08-26
-
Diff: 2579 lines (+1390/-690)34 files modifieddebian/control (+2/-12)
debian/qtdeclarative5-ubuntu-web-plugin-assets.install (+0/-1)
debian/rules (+0/-4)
doc/WebView.qdoc (+44/-5)
src/Ubuntu/Web/CMakeLists.txt (+0/-3)
src/Ubuntu/Web/Selection.qml (+0/-161)
src/Ubuntu/Web/SelectionHandle.qml (+0/-47)
src/Ubuntu/Web/UbuntuWebView02.qml (+60/-156)
src/Ubuntu/Web/selection02.js (+2/-131)
src/app/CMakeLists.txt (+1/-0)
src/app/FileExtensionMapper.js (+11/-7)
src/app/FilePickerDialog.qml (+2/-2)
src/app/WebViewImpl.qml (+20/-9)
src/app/actions/Cut.qml (+23/-0)
src/app/actions/Erase.qml (+23/-0)
src/app/actions/Paste.qml (+23/-0)
src/app/actions/Redo.qml (+23/-0)
src/app/actions/SaveLink.qml (+23/-0)
src/app/actions/SelectAll.qml (+23/-0)
src/app/actions/Undo.qml (+23/-0)
src/app/browserapplication.cpp (+9/-0)
src/app/mime-database.cpp (+33/-0)
src/app/mime-database.h (+39/-0)
src/app/webbrowser/Browser.qml (+103/-26)
src/app/webbrowser/ContextMenuMobile.qml (+168/-0)
src/app/webbrowser/ContextMenuWide.qml (+158/-0)
src/app/webbrowser/assets/stock_link.svg (+164/-0)
src/app/webcontainer/WebViewImplOxide.qml (+42/-5)
tests/autopilot/webbrowser_app/emulators/browser.py (+33/-16)
tests/autopilot/webbrowser_app/tests/http_server.py (+28/-0)
tests/autopilot/webbrowser_app/tests/test_contextmenu.py (+177/-0)
tests/autopilot/webbrowser_app/tests/test_selection.py (+0/-92)
tests/unittests/qml/tst_FileExtensionMapper.qml (+39/-0)
tests/unittests/qml/tst_UbuntuWebView02.qml (+94/-13)
- Chris Coulson: Pending requested 2015-09-08
-
Diff: 193 lines (+55/-9)7 files modifiedqt/tests/qmltests/api/tst_WebView_contextMenu.qml (+7/-4)
shared/browser/oxide_resource_dispatcher_host_delegate.cc (+12/-1)
shared/browser/oxide_web_context_menu.cc (+16/-1)
shared/common/oxide_constants.cc (+4/-1)
shared/common/oxide_constants.h (+5/-2)
shared/renderer/oxide_content_renderer_client.cc (+8/-0)
shared/renderer/oxide_content_renderer_client.h (+3/-0)
| Olivier Tilloy (osomon) wrote : | #1 |
| Olivier Tilloy (osomon) wrote : | #2 |
Just tested with hyperlinks that embed a mimetype definition (e.g. <a href="file.pdf" type="applicati
| Olivier Tilloy (osomon) wrote : | #3 |
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 : | #4 |
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 : | #5 |
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.
| Changed in canonical-devices-system-image: | |
| milestone: | none → ww40-2015 |
| assignee: | nobody → David Barth (dbarth) |
| importance: | Undecided → High |
| status: | New → Confirmed |
| 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 : | #6 |
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 : | #7 |
Fixed in oxide 1.10.4-
| Changed in canonical-devices-system-image: | |
| status: | In Progress → Fix Committed |
| Changed in canonical-devices-system-image: | |
| status: | Fix Committed → Fix Released |
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.