Expose 'unsupportedContent' and 'downloadRequested' style signals
Bug #1282063 reported by
Michael Sheldon
This bug affects 2 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Oxide |
Fix Released
|
High
|
Alexandre Abreu | ||
| webbrowser-app |
Fix Released
|
High
|
Alexandre Abreu | ||
Bug Description
QWebView features an "unsupportedCon
In addition to this there's also a "downloadRequested" signal which indicates that the user has explicitly requested the download of a particular URL (e.g. saving an HTML page or an image). I suspect this will be more involved as there'd also need to be a way to actually make these requests in the UI.
Related branches
lp:~abreu-alexandre/oxide/add-download-requested-support
- Chris Coulson: Approve
-
Diff: 1088 lines (+803/-1)23 files modifiedpatches/add-should-download-url-to-resource-dispatcher-host.patch (+125/-0)
patches/series (+1/-0)
qt/core/api/oxideqdownloadrequest.cc (+98/-0)
qt/core/api/oxideqdownloadrequest.h (+66/-0)
qt/core/api/oxideqdownloadrequest_p.h (+51/-0)
qt/core/browser/oxide_qt_web_view.cc (+20/-0)
qt/core/browser/oxide_qt_web_view.h (+7/-0)
qt/core/core.gyp (+9/-0)
qt/core/glue/oxide_qt_web_view_adapter.h (+3/-0)
qt/quick/api/oxideqquickwebview.cc (+7/-0)
qt/quick/api/oxideqquickwebview_p.h (+2/-0)
qt/quick/api/oxideqquickwebview_p_p.h (+2/-0)
qt/quick/oxide_qml_plugin.cc (+3/-0)
qt/tests/qmltests/api/tst_WebView_downloadRequested.py (+20/-0)
qt/tests/qmltests/api/tst_WebView_downloadRequested.qml (+58/-0)
qt/tests/qmltests/api/tst_WebView_downloadRequestedUnhandledMimeType.py (+18/-0)
shared/browser/oxide_content_browser_client.cc (+8/-0)
shared/browser/oxide_content_browser_client.h (+15/-1)
shared/browser/oxide_resource_dispatcher_host_delegate.cc (+162/-0)
shared/browser/oxide_resource_dispatcher_host_delegate.h (+92/-0)
shared/browser/oxide_web_view.cc (+18/-0)
shared/browser/oxide_web_view.h (+16/-0)
shared/shared.gyp (+2/-0)
| Changed in oxide: | |
| importance: | Undecided → High |
| status: | New → Triaged |
| Changed in webbrowser-app: | |
| status: | New → Triaged |
| importance: | Undecided → High |
| assignee: | nobody → Olivier Tilloy (osomon) |
Revision history for this message
| Michael Sheldon (michael-sheldon) wrote | #1 |
| Changed in oxide: | |
| assignee: | nobody → Alexandre Abreu (abreu-alexandre) |
| Changed in webbrowser-app: | |
| assignee: | Olivier Tilloy (osomon) → Alexandre Abreu (abreu-alexandre) |
| Changed in oxide: | |
| status: | Triaged → In Progress |
| Changed in webbrowser-app: | |
| status: | Triaged → In Progress |
| tags: | added: rtm14 |
| Changed in oxide: | |
| milestone: | none → branch-1.1 |
| Changed in webbrowser-app: | |
| milestone: | none → feature-freeze |
| Changed in oxide: | |
| status: | In Progress → Fix Released |
| Changed in webbrowser-app: | |
| status: | In Progress → Fix Released |
To post a comment you must log in.
After a bit of further work it looks like the "downloadRequested" signal probably isn't necessary (at least from the perspective of the webbrowser-app), as this can be handled purely within QML from the context actions. So only "unssportedContent" is needed for file types that the browser can't display natively.