Group commands related to commands/commandline by prefixing them with `cmd-`. In this
case we additionally renamed the command slightly to fit better with the `cmd-` prefix.
Group commands related to commands/commandline by prefixing them with `cmd-`. In this
case we additionally renamed the command slightly to fit better with the `cmd-` prefix.
With Qt 6.3+, user interaction is required to navigate outside of qute:// from a
qute:// page.
Fixes#7815
See #7220 - should be revisited once we have a qute-bookmarks:// instead where
we can adjust permissions when registering the URL handler.
Needed mostly for urlmarks BDD tests so they can clear things between tests.
Hopefully with --all, this won't be accidentally triggered by users.
Preparation for #7815
While not documented that way:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/cwait?view=msvc-170
It looks like that Windows sometimes sets errno to EACCES here (causing a
PermissionError):
> os.waitpid(pid, 0) # pid, options... positional-only :(
E PermissionError: [Errno 13] Permission denied
I have no idea why it happens, but it results in flaky tests on CI.
We aren't particularly interested in this (we just want to make sure the process
is cleaned up before the next test runs...), so let's just ignore this.
We're deprecating vim modelines in favor of `.editorconfig`.
Removing vim modelines could be done using two one-liners. Most of the vim modelines
were followed by an empty line, so this one-liner took care of these ones:
```sh
rg '^# vim: .+\n\n' -l | xargs sed -i '/^# vim: /,+1d'
```
Then some of the vim modelines were followed by a pylint configuration line, so running
this one-liner afterwards took care of that:
```sh
rg '^# vim:' -l | xargs sed -i '/^# vim: /d'
```
For unknown reasons, on nightly CI we now get TWO errors:
<qutebrowser.browser.webkit.certificateerror.CertificateErrorWrapper errors=['NoPeerCertificate', 'SelfSignedCertificate'] string='The peer did not present any certificate\nThe certificate is self-signed, and untrusted'>
TL;DR: I think I stabilized a couple of hinting iframe tests and applied
that change to all the iframe usages in the end2end tests in the hopes
that it would resolve some other flaky tests.
I was facing some tests that hinted elements in iframes failing
intermittently recently. They were most consistently failing on the
windows runner. This is similar to the trend described in the comment
linked from #1525.
The tests failing recently where:
tests (py39-pyqt515, windows-2019, 3.9)
test_using_hintfollow_inside_an_iframe
test_using_hintfollow_inside_an_iframe_button
tests (py311-pyqt515, ubuntu-20.04, 3.11)
test_using_hintfollow_inside_an_iframe
test_using_hintfollow_inside_an_iframe_button
They are failing because hints don't get generated for the elements in
the iframe. I can see hints do get generated for the iframe itself
though.
Examining the logs in 5.15 it seems that there is a
`cur_load_finished(True) (tab *)` log line after we run :hint. I suspect
that this is the load finished signal for the iframe.
I attempted to change the bdd open_path function to wait for the current
message it's looking for and then additionally look for that
cur_load_finished signal, but then it starts failing locally when the
iframe load signal actually comes before the parent frame one. Just
looking for the cur_load_finished signal itself also always found it
immediately ("already found"), probably from the parent frame.
So instead of trying to deal with that indeterminate ordering or
trying to change the signals to say what frame they are coming from, I
added javascript to all the pages used in iframes that run on load, and
changed all the tests to watch for log messages from the JS.
It's not the most maintainable solution, perhaps if we generated our
test files with jinja we could have some "subframe loaded" boilerplate,
get a message to log from a query param, look at metadata from test
files for the open_path checking etc.
I then searched for all the iframe usages in the test data and applied
that change to all of those files and all the tests that used them. A
few of those tests also had `flaky` annotations on them. I removed those
annotations for now in the hopes that there were affected by the same
problem. And that I actually managed to work around it correctly.
ref: #7621
This was first introduced in adbdfcbad3,
most likely because we got logging from the built-in Werkzeug webserver.
It doesn't seem to be needed anymore, possibly since
41c4ee3e2f where we started using CherryPy
for the SSL server too.
This should fix nighly bleeding tests, because the before_first_request
decorator got removed in Flask:
https://github.com/pallets/flask/pull/4621https://github.com/pallets/flask/pull/4995
There's some weird issue with Qt6.4 and 6.5 where a webengine view gets
its widget swapped out when it gets history deserialized into it. While
it's swapping widgets it has no so the focus gets passed to some other
widget should never even have focus.
There's probably more comprehensive ways we could handle this, by
overriding the WebEngineView layout, or by overriding focusNextPrevChild
on the parent to put out own logic into the "child is going, pass focus
to parent" logic chain.
But all that seems like a bit too much of a headache for this very
focussed issue. We want the new tab to get focus, so lets re-focus it.
Technically we could just focus the last tab that we open, if we are
undoing multiple, but the existing logic is to open each of them in turn
as foreground tabs and this reinforces that.
Closes: #7623
Not sure why its failing on windows, but it only really needs to run in
one environment anyway.
Previously this was using chrome://gpu but that was failing on CI due to
it invoking some vulkan stuff the didn't work without a GPU. I changed
it to chrome://sandbox/ for no good reason, but it seems to be working
fine on ubuntu at least.
Follow up to 151d808940
This one is for 6.5. Interesting that it was fine on 6.4.
I haven't gone and added text to all the test file because I'm hoping
it'll be something that upstream addresses in short order. So I'm only
adding text to files used by failing tests.
See d413b87c3f#7621 and #7624
On GH actions I'm seeing an "unexpected line" failure around creating a
vulkan context when loading chrome://gpu
ERROR tests/end2end/features/test_tabs_bdd.py::test_cloning_a_tab_with_a_special_url - end2end.fixtures.testprocess.InvalidLine:
1829
Error: vkCreateInstance failed with VK_ERROR_INCOMPATIBLE_DRIVER
1830
at CheckVkSuccessImpl (../../../3rdparty/chromium/third_party/dawn/src/dawn/native/vulkan/VulkanError.cpp:88)
1831
at CreateVkInstance (../../../3rdparty/chromium/third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:360)
1832
at Initialize (../../../3rdparty/chromium/third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:235)
1833
at Create (../../../3rdparty/chromium/third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:165)
1834
at operator() (../../../3rdparty/chromium/third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:420)
I'm not sure its actually failing the test, we are just seeing the error
in the logs and flagging it.
Instead of adding the logs to an ignore list I'm going to switch the
page we use so that if the error comes up for real we'll be sure to see
the logs.
I don't quite understand why the value changed from #00000 to #121212
there with Qt 6.3, but it looks like the change is here to stay.
Instead of keeping #000000 the default and adding an override for every
new Qt release, let's just switch over and add an override for the old
versions (5.15 and 6.2), so this won't break again for every new release.
See #7624
This reverts commit 47be6f3aeb.
This doesn't really make sense in test files, as the warning would point
inside some internal pytest code, which is not helpful.
Instead, let's just disable the corresponding flake8 warning in tests.
flake8-bugbear B028 No explicit stacklevel keyword argument found. The
warn method from the warnings module uses a stacklevel of 1 by default.
This will only show a stack trace for the line on which the warn method
is called. It is therefore recommended to use a stacklevel of 2 or
greater to provide more information to the user.
Semgrep helped:
semgrep --lang=py -e 'warnings.warn($ARG)' --replacement 'warnings.warn($ARG, stacklevel=2)' $FILES -a
semgrep --lang=py -e 'warnings.warn($ARG1, $ARG2)' --replacement 'warnings.warn($ARG1, $ARG2, stacklevel=2)' $FILES -a
Although it did lose the f-string on one of them.
Mostly pretty lazy fixes. Most of the places in the tests we were
already matching on error message, a couple of places we weren't. The
tick-tock one was the only one that wasn't being used right where it was
raised.
Some of them I just changed to RuntimeError because it was shorter than
adding the pylint directive.
The "Answering a question for a cancelled download" test was flaky,
due to the preceding PDF.js test sometimes not waiting properly for its
download to finish: "I wait until the download is finished" waited for
the initial PDF download above (which causes PDF.js to open), but not
for the real download after clicking the save button.
See #5390
TODO: Cherry-pick to master?
With Qt 6, the default changed to Qt handling network redirects instead of us
doing so manually. This seems like a good thing, so instead of setting the
redirect policy back to QNetworkRequest.RedirectPolicy.ManualRedirectPolicy,
let's just let Qt handle everything.
By default, Qt allows 50 redirects before giving up. That seems a tad much, so
we set it back to our former default.
This change comes with a few changes in behavior:
- Redirects to the same URL now fail (too many redirects) rather than being
ignored. I'm not sure how the previous behavior was useful. We added it in the
initial implemetation in 6856c49be9 (later
refactored a bit in 70e390a2e8) and added a test
in d13f88f0ac. But it doesn't make sense...
- We use QNetworkRequest.RedirectPolicy.NoLessSafeRedirectPolicy (no HTTPS ->
HTTP redirects allowed), while the former behavior didn't validate redirects
at all. Interestingly enough, I can't get Chromium to error out in that case
for downloads (though I only tried on localhost with a self-signed
certificate). However, it seems like a reasonable default.
Test will be added in a follow-up commit.
- Partially downloaded files aren't deleted anymore on a "too many redirect"
error. This should be solved in a more generic way, will do so in a follow-up
commit.
TODO: Pick to master?
Fixes#2679.
Not sure why we didn't do this initially, maybe it wasn't possible: https://webpy.org/cookbook/ssl
This means we don't need to (ab)use the Flask development server anymore.
We used to dodge these by listening on 0.0.0.0. Now they are on to us
and always show the warnings. Running flask in development mode here is
intended, so lets not have the warnings fail the tests.
Ref: https://github.com/pallets/werkzeug/issues/2480
When e.g. doing:
- '?foo' (search with reverse=True -> FindBackwards)
- 'N' (prev_result -> no FindBackwards)
- 'n' (next_result -> FindBackwards again)
we need to take a copy of the flags so that we can temporarily clear
FindBackwards when pressing 'N'.
Relevant history:
- We originally did int(self._flags) in
d450257485.
- In f0da508c21, we used
QWebPage.FindFlags(int(self._flags)) instead.
- With 97bdcb8e674c8ff27ab92448effef263880ab3aa (picked from
c349fbd180) we instead do:
flags = QWebEnginePage.FindFlag(self._flags)
Using FindFlag instead of FindFlags seemed to work fine with PyQt6 and
enum.Flag. With PyQt5, however, later clearing a flag bit ends up with us
getting 0 as an integer, thus losing the type information about this being a
FindFlag instance, and resulting in a TypeError when calling into Qt.
We could use FindFlags() with PyQt 6 but FindFlag() with PyQt 5 to copy the
original flags, but that's getting rather cumbersome. Instead, let's have a
helper dataclass of bools, do away with the bit-twiddling, and only convert it
to a Qt flags when we actually need them. This solves the copying issue nicely,
and also makes the code a lot nicer.
Finally, this also adds a test case which fails when the flags are mutated in
place instead of copied.
We could do the same kind of change for QtWebKit as well, but given that it's
somewhat dead - and perhaps more importantly, won't run with Qt 6 - let's not
bother. To not break the end2end tests with QtWebKit, the output still is the
same as before.
(cherry picked from commit 96a0cc39512753445bc7a01b218b2f1290819ddd)
The PyQt resources system is gone in 6.2 and deprecated before that. This
should be the last usage of it.
Switches icons to be read with `utils.resources.read_file_binary()` in
`notification.py` (fallback desktop notification icon) and `app.py` (icon for
the desktop window).
importlib only loads resources under a package, so the icons are moved under
the `qutebrowser/` directory.
Closes: #6062
Commits for dropping 3.5 support to copy from:
c245b7d855ccd "Initial drop of Python 3.5"
ccdfb44b85 "Drop support for Python 3.6.0"
Anything needed to update regarding OS version support in
doc/install.asciidoc?
TODO: remove 3.6/7 annotations in requirements files and
rebuild
workflows: not sure I updated it right (run 5.12 with 3.7, same 18.04 OS) but
18.04 seems to have 3.7 on it too so it should work. It'll all change when we
drop <5.15 anyway. Not sure what the minimum ubuntu version will be going
forward.
Regarding mimetype overrides (ebb3046822) the doctring says they can all go
in 3.7 but .h5 is still missing on py39, not sure if we should care.
There are a bunch of old(?) warning messages still ignored in tests/end2end/fixtures/quteprocess.py.
Refactor the magic tag creation thing to add python version checking support.
Makes `_check_version()` support checking plain tuples to so that I don't have
to copy the operator dict.
Now most of the branches of the if/else are the same, meh.
One can override the auto-detection mechanism by passing
the backend via --qute-bdd-backend=<backend> or by setting the
environment variable QUTE_BDD_BACKEND=<backend>.
Test originally expected "Baz" instead of "baz", which is what should
actually be found if starting at the bottom and then searching forward
(wrapping around).
If we're not waiting for the async INSERT in the SQL database, it can happen
that :debug-dump-history gets called before the history entry was addeded to the
actual database.
See #5390
The underlying Chromium pads images so that scanlines align on 4-byte
boundaries. Thus, with an image size of e.g. 239x239, we'll have 3 bytes
of padding (239 mod 4 = 3; 240 mod 4 = 0).
Fixes#6375
Philipp Albrecht
Florian Bruhin
toofar
Kian-Meng Ang
Nicholas Schwab
Axel Dahlberg
Jimmy
Tim Gadanidis
harish3124
Philipp Albrecht
Charlotte Van Petegem
Nicholas Boyd Isacsson
phesch