This exposes all possible values, but before
https://codereview.qt-project.org/#/c/240121/ we won't be able to change those
at runtime (or enable URL patterns, which thankfully weren't enabled for the
old setting).
In theory, it'd be possible to handle the "public-interface-only" value via
QWebEngineSettings without requiring a restart, but it isn't worth the trouble.
Closes#4201
In Qt < 5.10 (and also sometimes on Windows), we get extra spaces or newlines
when moving to the end of the document. However, this only happens *sometimes*,
and manual testing confirms that with the current workaround, we actually lose
the last char in the selection.
I'm not sure what's happening there, but instead of making things worse with
the workaround, let's just be a bit less strict with the checking there and
accept both variants... This seems like some Chromium bug we can't do much
about.
Resolves#4199.
To avoid accidentally highlighting characters that were introduced by
html escaping the text before feeding it to setHtml, we can't just
escape the whole string before adding the highlighting. Instead, we need
to break the string up on the pattern, format and escape the individual
parts, then join them back together.
re.escape includes empty strings if there is a match at the start/end,
which ensures that matches always land on odd indices:
https://docs.python.org/3/library/re.html#re.split
> If there are capturing groups in the separator and it matches at the
> start of the string, the result will start with an empty string. The
> same holds for the end of the string
Resolves the example case in #4199, but not the larger problem. We don't
need to escape quotes as we don't put the string in an attribute value.
From the docs at
https://docs.python.org/3/library/html.html#html.escape:
> If the optional flag quote is true, the characters (") and (') are also
> translated; this helps for inclusion in an HTML attribute value
> delimited by quotes, as in <a href="...">.
Escaping quotes means we end up with a literal ' in the completion
view wherever there is a quote in the source text.
However, problem in #4199, where unexpected parts of the text are
highlighted, can also happen with '<', '>', and '&', which still must be
escaped.
There were no unit tests for this whole module. It is difficult to test
due to all the private logic and Qt dependencies, but with a lot of
mocking we can at least validate some of the text handling.
This is a setup to start testing the solution to #4199.
I picked '{' and '}' as placeholders in the test data because they draw
the eye to the 'highlighted' part, and vim even highlights them with
python syntax highlighting. It could be confusing though, as they look
like format strings but are not used that way.
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.
Previously calling `script.code()` would fail if the script didn't have
a `name`. This wasn't being hit in practice because the only place that
constructs GreasemonkeyScripts was checking for that condition and add
the filename there as a fallback.
This change make the `name` attribute more explicitly mandatory by
failing with a `ValueError` if it is not provided and make it still
possible to use the filename fallback in that case by adding a
`filename` keyward argument to `__init__()`.
Additionally where `script_meta` is used in `script.code()` a fallback
to and emptry string was added so it doesn't fail for raw javascript
files without greasemonkey metadata.
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.
For some reason I don't comprehend right now, disabling it breaks
test_focusing_download_widget_via_tab. I'm having exams tomorrow and the day
after that, so meh, let's just re-enable that test for now as a stopgap
solution.
`ListCategory` sorts its completion by default, we are already building
the categories in the right order so don't need that.
The test tests the case of where you have 11 tabs and if the model was
sorted the tabs with index 10 and 11 would be sorted before the one with
index 2.
The `random.sample` bit for the tab url and title is to also make sure
the model isn't being sorted on those columns, whithout haveng to write
and all ten lines.
- Update the docstring for repeat
- Remove the blank line after the docstring
- Update the docstring with scripts/dev/src2asciidoc.py
- Simplify the test
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.
I was adding a downloads one and saw the opportunity to refactor. Didn't
end up saving that much because I couldn't figure out how to get the
method that does the work to use the fixtures while also taking an
argument, so they have to be passed through from the calling ones. Oh
well.
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.
