When we click the download button in PDF.js, it downloads a blob://qute:...
URL. We can detect that and force a download rather than opening it in PDF.js
again.
Note that what actually happens depends on the Qt version and backend:
QtWebKit (any Qt version):
Downloads always work properly (regardless of Qt version).
QtWebEngine, Qt 5.7.1:
Downloads work.
QtWebEngine, Qt 5.9 - 5.11:
Downloads won't work as we need to tell PDF.js to not use blob: URLs:
https://bugreports.qt.io/browse/QTBUG-70420 - in theory, PDF.js could fall back
to downloading the existing qute:// URL, but it has a whitelist of schemes
which does not include qute://... Since it's not in that whitelist, it just
ends up doing nothing at all.
QtWebEngine, Qt 5.12:
Downloads should hopefully work properly again, as we can register the qute://
scheme with Chromium, which allows us to use blob:// URLs.
This reverts commit 9c731bde85627308fdde4730b0181a014096cb47.
We need to set some PDF.js options, so we can't just use the default viewer
with ?file=...
Adds a new file for tests relating to WebEngineTab, it looks a little
sparse right now but I'm sure there will be more soon.
Tests that scripts with invalid world IDs are rejected appropriately and
the ones with valid world IDs aren't rejected.
The `FakeWidget` thing is so `sip.isdeleted` didn't complain about being
passed the wrong type.
If the blacklist is only valid for the completion, the setting should also be
under completion.
This also un-renames history.gap_interval and renames
completion.web_history_max_items.
This adds a new CompletionMetaInfo table which is a simple key/value store.
Thanks to Python/sqlite duck typing, we can use that to store values of any
type, even new ones in the future.
Currently, the only allowed key is force_rebuild, which forces a rebuild of the
CompletionHistory table. This will be needed for a future change.
In ffc29ee043 (part of v1.0.0), a
qute://settings/set URL was added to change settings.
Contrary to what I apparently believed at the time, it *is* possible for
websites to access `qute://*` URLs (i.e., neither QtWebKit nor QtWebEngine
prohibit such requests, other than the usual cross-origin rules).
In other words, this means a website can e.g. have an `<img>` tag which loads a
`qute://settings/set` URL, which then sets `editor.command` to a bash script.
The result of that is arbitrary code execution.
Fixes#4060
See #2332
I think this covers the right path despite not using either of the
backend specific download code. They both either call `set_target()`
directly with a guessed filename or from the prompt question. When
called directly though that basename set by `_init_item()` is used.
It's a little high level but we already know that sanitize_filenames
does, I wanted to test that it gets called.
This reverts commit 1956590df84a72c7f9a516e805d01529291fccf8.
Turns out the actual issue wasn't due to *invalid* links - it's with links
which have an unknown scheme.
There's still a change in behavior between Qt 5.10 and 5.11 though: Invalid
links are apparently not passed to acceptNavigationRequest (sometimes?) so we
don't show an error message. Instead, we just load about:blank. However,
Chromium does that too and we can't handle a real click easily, so let's just
ignore that one.
See #3661
When `@require`ing local files (with the `file://` scheme) the
greasemonkey manager was not catching the DownloadItem.finished signal
because it was being emitted before it had managed to connect.
I didn't see this happening while testing with files that should have
been in cache but I wouldn't be surprised.
I had to change the download mock to be able to give it the appearance
of asynchronicity. Now when using it one must set download.successful
appropriately before firing download.finished. I also added a list of
downloads to the stub so a test could enumerate them in case the
unit-under-test didn't have a reference to them.
This refactors the whole web(kit|engine|) settings mess a bit so there's a
Web(Kit|Engine)Settings object for (non-static) settings set on a
QWeb(Engine)Settings object in Qt. Everything else is set on module-level a bit
less declaratively.
The whole inheritance mess is gone, and we can now also construct a
Web(Kit|Engine)Settings object for a given tab.
Fixes#2701
We originally made it per-window in b502280c06 for
issue #228, but that was back when we still needed window IDs for stuff like
message.info.
Nowadays, there's no reason for it to be per-window anymore. The rest of the
download code can deal with one global download manager (because QtWebEngine has
one), and apart from QNAM code which wasn't used here anyways (as tab_id=None)
there was nothing using the window ID anymore.
Also see #3456 which was the original motivation for this change.
