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
For the LogFilter tests I just copied some of the examples that were
already being used and reversed them. To do that without even more
duplication I had to add another parameter to the test.
This codepath may trigger a crash which was fixed by
0e75f3272d.
However, this commit does not make it more likely to happen, and this
patch was backported into arch (at least).
In the future, we may be able to use <enter> on qtwebkit with js,
without triggering this crash
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
Turns out str.isdigit() also handles ² as a digit, but int('²') causes a
ValueError.
Here we use `string.digits` instead, which is '0123456789'.
Fixes#3743
Since `objects.backend` was being set to usertypes.Backend.QtWebKit by
default some feature detection code was calling
`version.qWebKitVersion()` which was failing because the import of
`PyQt5.QtWebKit` was failing in version.
This should not change behavior where both backends are available on if
any tests fail because they are expecting their environment to say they
are on webkit when they either aren't actually using any webkit features
or all mocked webkit features then they should probably be changed to
patch `objects.backend` or not depend on it.
I just want to return something I can refer to the attributes of via dot
syntax without having to pointlessly write the names both when I declare
the data class and when I assign the variables.
Such a stupid warning.
Since the JSCore used by WebKit 602.1 doesn't fully support Proxy and I
can't think of a way to provide isolation otherwise just revert to the
old behaviour in that case. I am checking for the specific WebKit
version because I'm pretty sure that version just happened to be
released when Proxy support was only partially done, any later release
will presumably have a newer JSCore where it works.
There I changed the indentation of a block in the jinja template which
will have inflated the diff.
I added mocking of `objects.backend` to the `webview` and
`webenginewebview` fixtures, I am pretty sure they are mutually
exclusive so don't expect any issues from that.
Because of the feature detection being at template compile time I had to
tweak the test setup to be done via a fixture instead of the setupClass
functionality that I was using before.
The implementation of Proxy in JSCore used by current QtWebkit (webkit
602.1) doesn't support the `set()` handler for whatever reason. So
instead of testing for a specific behaviour that we can't ensure on that
version let's just skip the tests and handle user complaints with
sympathy.
Adds a test to codify what I think greasemonkey scripts expect from
their scope chains. Particularly that they can:
1. access the global `window` object
2. access all of the attributes of the global window object as global
objects themselves
3. see any changes the page made to the global scope
4. write to attributes of `window` and have those attributes, and changes
to existing attributes, accessable via global scope
5. do number 4 without breaking the pages expectations, that is what
`unsafeWindow` is for
There are some other points about greasemonkey scripts' environment that
I believe to be true but am not testing in this change:
* changes a page makes to `window` _after_ a greasemonkey script is
injected will still be visible to the script if it cares to check and
it hasn't already shadowed them
* said changes will not overwrite changes that the greasemonkey script
has made.
